Network Working Group T. Melia, Ed.
Request for Comments: 5677 Alcatel-Lucent
Category: Standards Track G. Bajko
Nokia
S. Das
Telcordia Technologies Inc.
N. Golmie
NIST
JC. Zuniga
InterDigital Communications, LLC
December 2009
IEEE 802.21 Mobility Services Framework Design (MSFD)
Abstract
抽象
This document describes a mobility services framework design (MSFD) for the IEEE 802.21 Media Independent Handover (MIH) protocol that addresses identified issues associated with the transport of MIH messages. The document also describes mechanisms for Mobility Services (MoS) discovery and transport-layer mechanisms for the reliable delivery of MIH messages. This document does not provide mechanisms for securing the communication between a mobile node (MN) and the Mobility Server. Instead, it is assumed that either lower-layer (e.g., link-layer) security mechanisms or overall system-specific proprietary security solutions are used.
この文書では、MIHメッセージの輸送に関連した特定された問題に対処するIEEE 802.21メディア独立ハンドオーバー（MIH）プロトコルのためのモビリティサービスフレームワークの設計（MSFD）について説明します。文書はまた、MIHメッセージの信頼性の高い配信のためのモビリティサービス（MOS）の発見とトランスポート層のメカニズムのための仕組みを説明しています。この文書では、モバイルノード（MN）のモビリティサーバ間の通信を確保するためのメカニズムを提供しません。その代わりに、下位層（例えば、リンク層）セキュリティメカニズムまたは全体的なシステム固有の独自のセキュリティソリューションのいずれかが使用されているものとします。
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
IESG Note
IESG注意
As described later in this specification, this protocol does not provide security mechanisms. In some deployment situations lower-layer security services may be sufficient. Other situations require proprietary mechanisms or as yet incomplete standard mechanisms, such as the ones currently considered by IEEE. For these reasons, the specification recommends careful analysis before considering any deployment.
本明細書で後述するように、このプロトコルは、セキュリティ・メカニズムを提供しません。いくつかの配備状況では、下位層のセキュリティサービスは十分であろう。他の状況は、現在IEEEによって検討するものとして独自の機構またはまだ不完全な標準的なメカニズムを必要とします。これらの理由から、仕様はどんな展開を検討する前に慎重に分析することをお勧めします。
The IESG emphasizes the importance of these recommendations. The IESG also notes that this specification deviates from the traditional IETF requirement that support for security in the open Internet environment is a mandatory part of any Standards Track protocol specification. An exception has been made for this specification, but this should not be taken to mean that other future specifications are free from this requirement.
IESGは、これらの推奨事項の重要性を強調しています。 IESGはまた、この仕様は、任意の標準化過程プロトコル仕様の必須部分であるオープンなインターネット環境でのセキュリティのためにサポートし、伝統的なIETF要件から外れていることを指摘しています。例外は、この仕様のために作られましたが、これは、他の将来の仕様は、この要件から自由であることを意味すると解釈されるべきではありません。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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 BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................4
2.1. Requirements Language ......................................7
3. Deployment Scenarios ............................................7
3.1. Scenario S1: Home Network MoS ..............................8
3.2. Scenario S2: Visited Network MoS ...........................8
3.3. Scenario S3: Third-Party MoS ...............................9
3.4. Scenario S4: Roaming MoS ...................................9
4. Solution Overview ..............................................10
4.1. Architecture ..............................................11
4.2. MIHF Identifiers (FQDN, NAI) ..............................12
5. MoS Discovery ..................................................12
5.1. MoS Discovery When MN and MoSh Are in the Home
Network (Scenario S1) .....................................13
5.2. MoS Discovery When MN and MoSv Both Are in Visited
Network (Scenario S2) .....................................14
5.3. MoS Discovery When MIH Services Are in a
Third-Party Remote Network (Scenario S3) ..................14
5.4. MoS Discovery When the MN Is in a Visited Network
and Services Are at the Home Network (Scenario S4) ........15
6. MIH Transport Options ..........................................15
6.1. MIH Message Size ..........................................16
6.2. MIH Message Rate ..........................................17
6.3. Retransmission ............................................17
6.4. NAT Traversal .............................................18
6.5. General Guidelines ........................................18
7. Operation Flows ................................................19
8. Security Considerations ........................................21
8.1. Security Considerations for MoS Discovery .................21
8.2. Security Considerations for MIH Transport .................21
9. IANA Considerations ............................................22
10. Acknowledgements ..............................................23
11. References ....................................................23
11.1. Normative References .....................................23
11.2. Informative References ...................................23
This document proposes a solution to the issues identified in the problem statement document [RFC5164] for the layer 3 transport of IEEE 802.21 MIH protocols.
このドキュメントでは、IEEE 802.21 MIHプロトコルのレイヤ3の輸送のための問題声明ドキュメント[RFC5164]で特定された問題に対する解決策を提案しています。
The MIH Layer 3 transport problem is divided into two main parts: the discovery of a node that supports specific Mobility Services (MoS) and the transport of the information between a mobile node (MN) and the discovered node. The discovery process is required for the MN to obtain the information needed for MIH protocol communication with a peer node. The information includes the transport address (e.g., the IP address) of the peer node and the types of MoS provided by the peer node.
具体的なモビリティサービス（MOS）とモバイルノード（MN）と発見されたノード間の情報の転送をサポートするノードの発見：MIHレイヤ3トランスポートの問題は、主に2つの部分に分かれています。発見プロセスは、ピア・ノードとのMIHプロトコル通信に必要な情報を取得するためにMNのために必要とされます。情報は、ピア・ノードとピア・ノードによって設けられたMOSのタイプのトランスポートアドレス（例えば、IPアドレス）を含みます。
This document lists the major MoS deployment scenarios. It describes the solution architecture, including the MSFD reference model and MIHF identifiers. MoS discovery procedures explain how the MN discovers Mobility Servers in its home network, in a visited network or in a third-party network. The remainder of this document describes the MIH transport architecture, example message flows for several signaling scenarios, and security issues.
この文書では、大手のMoS展開シナリオを示しています。これは、MSFD参照モデルとMIHF識別子を含め、ソリューション・アーキテクチャについて説明します。 MoSの発見手順は、MNが訪問先ネットワーク内またはサードパーティ製のネットワークでは、そのホームネットワーク内のモビリティサーバを発見する方法を説明します。この文書の残りは、MIHトランスポートアーキテクチャを記述する例メッセージは、いくつかのシグナリングのシナリオ、およびセキュリティ上の問題のために流れます。
This document does not provide mechanisms for securing the communication between a mobile node and the Mobility Server. Instead, it is assumed that either lower layer (e.g., link layer) security mechanisms, or overall system-specific proprietary security solutions, are used. The details of such lower layer and/or proprietary mechanisms are beyond the scope of this document. It is RECOMMENDED against using this protocol without careful analysis that these mechanisms meet the desired requirements, and encourages future standardization work in this area. The IEEE 802.21a Task Group has recently started work on MIH security issues that may provide some solution in this area. For further information, please refer to Section 8.
この文書では、モバイルノード及びモビリティサーバ間の通信を確保するためのメカニズムを提供しません。代わりに、下位層（例えば、リンクレイヤ）セキュリティメカニズム、または全体的なシステム固有の独自のセキュリティソリューションのいずれかが、使用されているものとします。このような下部層及び/又はプロプライエタリメカニズムの詳細は、この文書の範囲を超えています。これは、これらのメカニズムが必要な要件を満たしていることを慎重に分析することなく、このプロトコルを使用しないことを推奨し、この分野での今後の標準化作業を奨励しています。 IEEE 802.21aタスクグループは最近、この分野でいくつかの解決策を提供することができるMIHのセキュリティ問題に関する作業を開始しました。詳細については、第8章を参照してください。
The following acronyms and terminology are used in this document:
以下の頭字語および用語は、このドキュメントで使用されています。
Media Independent Handover (MIH): the handover support architecture defined by the IEEE 802.21 working group that consists of the MIH Function (MIHF), MIH Network Entities, and MIH protocol messages.
メディア独立ハンドオーバ（MIH）：MIH機能（MIHF）、MIHネットワークエンティティとMIHプロトコルメッセージで構成され、IEEE 802.21ワーキンググループによって定義されたハンドオーバをサポートアーキテクチャ。
Media Independent Handover Function (MIHF): a switching function that provides handover services including the Event Service (ES), Information Service (IS), and Command Service (CS), through service access points (SAPs) defined by the IEEE 802.21 working group [IEEE80221].
メディア独立ハンドオーバ機能（MIHF）：イベントサービス（ES）、情報サービス（IS）、およびコマンドサービス（CS）を含むハンドオーバサービスを提供し、スイッチング機能、IEEE 802.21ワーキンググループによって定義されたサービスアクセスポイント（SAP）を介して、 【IEEE80221]。
MIHF User: An entity that uses the MIH SAPs to access MIHF services, and which is responsible for initiating and terminating MIH signaling.
MIHFユーザ：MIHFサービスにアクセスするためのMIH SAPを使用するエンティティ、およびそのMIHシグナリングを開始し、終了するための責任があります。
Media Independent Handover Function Identifier (MIHFID): an identifier required to uniquely identify the MIHF endpoints for delivering mobility services (MoS); it is implemented as either a FQDN or NAI.
メディア独立ハンドオーバ機能識別子（MIHFID）：一意的モビリティ・サービスを提供するためのMIHFエンドポイント（MOS）を識別するために必要な識別子。それは、FQDNまたはNAIとして実装されます。
Mobility Services (MoS): composed of Information Service, Command Service, and Event Service provided by the network to mobile nodes to facilitate handover preparation and handover decision, as described in [IEEE80221] and [RFC5164].
モビリティサービス（MOS）：[IEEE80221]と[RFC5164]で説明されるように情報サービス、コマンド・サービス、およびイベントサービスで構成されるが、ハンドオーバ準備ハンドオーバ決定を容易にするために、モバイルノードにネットワークによって提供されます。
MoSh: Mobility Services provided by the mobile node's Home Network.
モッシュ：モバイルノードのホームネットワークによって提供モビリティサービス。
MoSv: Mobility Services provided by the Visited Network.
MOSV：訪問先ネットワークにより提供されるモビリティサービス。
MoS3: Mobility Services provided by a third-party network, which is a network that is neither the Home Network nor the current Visited Network.
MOS3：ホームネットワークや現在の訪問先ネットワークでもないネットワークであるサードパーティ製のネットワークが提供するモビリティサービス。
Mobile Node (MN): an Internet device whose location changes, along with its point of connection to the network.
移動ノード（MN）：その位置の変化、ネットワークへの接続のその点と共にインターネットデバイス。
Mobility Services Transport Protocol (MSTP): a protocol that is used to deliver MIH protocol messages from an MIHF to other MIH-aware nodes in a network.
モビリティサービストランスポートプロトコル（MSTP）：ネットワーク内の他のMIH対応のノードにMIHFからMIHプロトコルメッセージを配信するために使用されるプロトコル。
Information Service (IS): a MoS that originates at the lower or upper layers of the protocol stack and sends information to the local or remote upper or lower layers of the protocol stack. The purpose of IS is to exchange information elements (IEs) relating to various neighboring network information.
情報サービス（IS）のMoSプロトコルスタックの下位または上位層に由来し、プロトコルスタックのローカルまたはリモートの上部または下部レイヤに情報を送信します。 ISの目的は、様々な隣接ネットワーク情報に関する情報要素（IE）を交換することです。
Event Service (ES): a MoS that originates at a remote MIHF or the lower layers of the local protocol stack and sends information to the local MIHF or local higher layers. The purpose of the ES is to report changes in link status (e.g., Link Going Down messages) and various lower layer events.
イベントサービス（ES）：リモートMIHFまたはローカルプロトコルスタックの下位層で発生し、地域MIHFまたはローカル上位層に情報を送信したMoS。 ESの目的は、リンク状態の変化（例えば、リンクがメッセージをゴーイング・ダウン）と、様々な下層イベントを報告することです。
Command Service (CS): a MoS that sends commands from the remote MIHF or local upper layers to the remote or local lower layers of the protocol stack to switch links or to get link status.
コマンド・サービス（CS）：リンクを切り替えるか、リンクステータスを取得するには、リモートMIHFまたはプロトコルスタックのリモートまたはローカル下位層へのローカル上位層からのコマンドを送信したMoS。
Fully Qualified Domain Name (FQDN): a complete domain name for a host on the Internet, showing (in reverse order) the full delegation path from the DNS root and top-level domain down to the host name (e.g., myexample.example.org).
完全修飾ドメイン名（FQDN）：（逆の順序で）ホスト名（例えば、myexample.exampleまでのDNSルートとトップレベルドメインからの完全な委任パスを示すインターネット上のホストの完全なドメイン名、。 ORG）。
Network Access Identifier (NAI): the user ID that a user submits during network access authentication [RFC4282]. For mobile users, the NAI identifies the user and helps to route the authentication request message.
ネットワークアクセス識別子（NAI）：ユーザがネットワークアクセス認証[RFC4282]の間に送信するユーザID。モバイルユーザーのために、NAIは、ユーザを識別し、ルートへの認証要求メッセージを支援します。
Network Address Translator (NAT): a device that implements the Network Address Translation function described in [RFC3022], in which local or private network layer addresses are mapped to routable (outside the NAT domain) network addresses and port numbers.
ネットワークアドレス変換（NAT）：ローカルまたはプライベートネットワーク層アドレスが（NATドメインの外側）ルータブルにマッピングされた[RFC3022]に記載されたネットワークアドレス変換機能、ネットワークアドレスとポート番号を実装するデバイス。
Dynamic Host Configuration Protocol (DHCP): protocols described in [RFC2131] and [RFC3315] that allow Internet devices to obtain respectively IPv4 and IPv6 addresses, subnet masks, default gateway addresses, and other IP configuration information from DHCP servers.
動的ホスト構成プロトコル（DHCP）：インターネット・デバイスは、DHCPサーバからそれぞれIPv4アドレスとIPv6アドレス、サブネットマスク、デフォルトゲートウェイアドレス、およびその他のIP構成情報を取得することができます[RFC2131]に記載されているプロトコルをし、[RFC3315]。
Domain Name System (DNS): a protocol described in [RFC1035] that translates domain names to IP addresses.
ドメインネームシステム（DNS）：ドメイン名をIPアドレスに変換します[RFC1035]に記載されているプロトコル。
Authentication, Authorization, and Accounting (AAA): a set of network management services that respectively determine the validity of a user's ID, determine whether a user is allowed to use network resources, and track users' use of network resources.
認証、認可、アカウンティング（AAA）：それぞれのユーザーのIDの有効性を判断するネットワーク管理サービスのセット、ユーザーがネットワークリソースを使用することが許可されているかどうか、およびネットワークリソースの利用者の利用状況を追跡。
Home AAA (AAAh): an AAA server located on the MN's home network.
ホームAAA（AAAhを）：MNのホームネットワーク上にあるAAAサーバ。
Visited AAA (AAAv): an AAA server located in a visited network that is not the MN's home network.
MNのホームネットワークではない訪問先ネットワークに配置AAAサーバ：AAA（AAAv）を訪問しました。
MIH Acknowledgement (MIH ACK): an MIH signaling message that an MIHF sends in response to an MIH message from a sending MIHF.
MIH肯定応答（ACK MIH）：MIHFは送信MIHFからMIHメッセージに応答して送信MIHシグナリングメッセージ。
Point of Service (PoS): a network-side MIHF instance that exchanges MIH messages with an MN-based MIHF.
サービス点（POS）：MNベースのMIHFとMIHメッセージを交換網側MIHFインスタンス。
Network Access Server (NAS): a server to which an MN initially connects when it is trying to gain a connection to a network and that determines whether the MN is allowed to connect to the NAS's network.
ネットワークアクセスサーバー（NAS）：ネットワークへの接続を獲得しようとしているときMNが最初に接続し、それはMNがNASのネットワークへの接続を許可されているかどうかを判断しているサーバ。
User Datagram Protocol (UDP): a connectionless transport-layer protocol used to send datagrams between a source and a destination at a given port, defined in RFC 768.
ユーザデータグラムプロトコル（UDP）：ソースおよびRFC 768で定義された指定されたポートで宛先との間でデータグラムを送信するために使用されるコネクションレスのトランスポート層プロトコル。
Transmission Control Protocol (TCP): a stream-oriented transport-layer protocol that provides a reliable delivery service with congestion control, defined in RFC 793.
伝送制御プロトコル（TCP）：RFC 793で定義された輻輳制御と信頼性の高い配信サービスを提供するストリーム指向のトランスポート層プロトコル。
Round-Trip Time (RTT): an estimation of the time required for a segment to travel from a source to a destination and an acknowledgement to return to the source that is used by TCP in connection with timer expirations to determine when a segment is considered lost and should be resent.
ラウンドトリップ時間（RTT）：セグメントを考慮するかを決定するためにタイマ満了に関連してTCPによって使用される元に戻すには、ソースから宛先確認応答に移動するセグメントに必要な時間の推定失われたと憤慨しなければなりません。
Maximum Transmission Unit (MTU): the largest size of an IP packet that can be sent on a network segment without requiring fragmentation [RFC1191].
最大伝送単位（MTU）：フラグメンテーション[RFC1191]を必要とすることなく、ネットワークセグメント上で送信することができるIPパケットの最大サイズ。
Path MTU (PMTU): the largest size of an IP packet that can be sent on an end-to-end network path without requiring IP fragmentation.
パスMTU（PMTU）：IP断片化を必要とすることなく、エンドツーエンドネットワークパス上で送信することができるIPパケットの最大サイズ。
Transport Layer Security Protocol (TLS): an application layer protocol that primarily assures privacy and data integrity between two communicating network entities [RFC5246].
トランスポート層セキュリティプロトコル（TLS）：主に2つの通信ネットワークエンティティ[RFC5246]の間でプライバシーとデータの整合性を保証アプリケーション層プロトコル。
Sender Maximum Segment Size (SMSS): size of the largest segment that the sender can transmit as per [RFC5681].
送信側最大セグメントサイズ（SMSS）：送信者は[RFC5681]に従って送信できる最大セグメントサイズ。
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 RFC 2119
[RFC2119].
This section describes the various possible deployment scenarios for the MN and the Mobility Server. The relative positioning of the MN and Mobility Server affects MoS discovery as well as the performance of the MIH signaling service. This document addresses the scenarios listed in [RFC5164] and specifies transport options to carry the MIH protocol over IP.
このセクションでは、MNとモビリティServer用の様々な可能性のある展開シナリオについて説明します。 MNとモビリティサーバの相対的な位置決めは、MOSの発見だけでなく、MIHシグナリングサービスのパフォーマンスに影響を与えます。この文書では、[RFC5164]に記載されているシナリオに対処し、IP上でMIHプロトコルを運ぶための輸送オプションを指定します。
In this scenario, the MN and the services are located in the home network. We refer to this set of services as MoSh as shown in Figure 1. The MoSh can be located at the access network the MN uses to connect to the home network, or it can be located elsewhere.
このシナリオでは、MNおよびサービスは、ホームネットワーク内に配置されています。モッシュはMNがホームネットワークに接続するために使用する、またはそれは他の場所に配置することができ、アクセスネットワークに配置することができる。図1に示すように、我々はモッシュなどのサービスのセットを参照してください。
+--------------+ +====+
| HOME NETWORK | |MoSh|
+--------------+ +====+
/\
||
\/
+--------+
| MN |
+--------+
Figure 1: MoS in the Home Network
図1：ホームネットワーク内のMOS
In this scenario, the MN is in the visited network and mobility services are provided by the visited network. We refer to this as MoSv as shown in Figure 2.
このシナリオでは、MNは訪問先ネットワーク内にあり、モビリティサービスは、訪問先ネットワークによって提供されています。図2に示すように、我々はMOSVとしてこれを参照してください。
+--------------+
| HOME NETWORK |
+--------------+
/\
||
\/
+====+ +-----------------+
|MoSv| | VISITED NETWORK |
+====+ +-----------------+
/\
||
\/
+--------+
| MN |
+--------+
Figure 2: MoSv in the Visited Network
図2：訪問先ネットワークでMOSV
In this scenario, the MN is in its home network or in a visited network and services are provided by a third-party network. We refer to this situation as MoS3 as shown in Figure 3. (Note that MoS can exist both in home and in visited networks.)
このシナリオでは、MNは、そのホームネットワークまたは訪問先ネットワーク内にあり、サービスは、サードパーティ製のネットワークによって提供されています。図3に示すように、我々はMOS3として、このような状況を参照してください（MOSは、家庭内および訪問先ネットワークの両方に存在することができることに注意してください。）
+--------------+
| HOME NETWORK |
+====+ +--------------+ +--------------+
|MoS3| | THIRD PARTY | <===> /\
+====+ +--------------+ ||
\/
+-----------------+
| VISITED NETWORK |
+-----------------+
/\
||
\/
+--------+
| MN |
+--------+
Figure 3: MoS from a Third Party
図3：第三者からのMoS
In this scenario, the MN is located in the visited network and all MIH services are provided by the home network, as shown in Figure 4.
このシナリオでは、MNは訪問先ネットワークに配置されており、図4に示すように、すべてのMIHサービスは、ホームネットワークによって提供されています。
+====+ +--------------+
|MoSh| | HOME NETWORK |
+====+ +--------------+
/\
||
\/
+-----------------+
| VISITED NETWORK |
+-----------------+
/\
||
\/
+--------+
| MN |
+--------+
Figure 4: MoS Provided by the Home While in Visited
図4：訪問中ながらホームで設けられたMOS
Different types of MoS can be provided independently of other types and there is no strict relationship between ES, CS, and IS, nor is there a requirement that the entities that provide these services should be co-located. However, while IS tends to involve a large amount of static information, ES and CS are dynamic services and some relationships between them can be expected, e.g., a handover command (CS) could be issued upon reception of a link event (ES). This document does not make any assumption on the location of the MoS (although there might be some preferred configurations), and aims at flexible MSFD to discover different services in different locations to optimize handover performance. MoS discovery is discussed in more detail in Section 5.
MoS異なる種類の独立して、他の種類の提供することができ、そこES、CSとの間に厳密な関係はなく、IS、また、これらのサービスを提供するエンティティが同じ場所に配置されなければならない要件があります。しかし、ISは、静的な大量の情報を必要とする傾向がある一方で、ESとCSが動的なサービスであり、それらの間にいくつかの関係が期待できるが、例えば、ハンドオーバコマンド（CS）は、リンクイベント（ES）の受信時に発行することができます。この文書では、（いくつかの好適な構成があるかもしれないが）のMoSの位置に任意の仮定を行い、ハンドオーバー性能を最適化するために、異なる場所で異なるサービスを発見するために柔軟MSFDすることを目的としません。 MoSの発見は第5節で詳しく説明されています。
As mentioned in Section 1, the solution space is being divided into two functional domains: discovery and transport. The following assumptions have been made:
発見と輸送：第1節で述べたように、解空間は、2つの機能領域に分割されています。以下の仮定がなされています。
o The solution is primarily aimed at supporting IEEE 802.21 MIH services -- namely, Information Service (IS), Event Service (ES), and Command Service (CS).
Oソリューションは、主にIEEE 802.21 MIHサービスをサポートすることを目的としている - すなわち、情報サービス（IS）、イベントサービス（ES）、およびコマンドサービス（CS）。
o If the MIHFID is available, FQDN or NAI's realm is used for mobility service discovery.
MIHFIDが利用可能な場合は、O、FQDNまたはNAIのレルムは、モビリティサービスの発見のために使用されています。
o The solutions are chosen to cover all possible deployment scenarios as described in Section 3.
Oソリューションは、セクション3で説明したように、すべての可能な展開シナリオをカバーするように選択されます。
o MoS discovery can be performed during initial network attachment or at any time thereafter.
OのMoSの発見は、初期ネットワーク接続中、またはその後の任意の時点で行うことができます。
The MN may know the realm of the Mobility Server to be discovered. The MN may also be pre-configured with the address of the Mobility Server to be used. In case the MN does not know what realm / Mobility Server to query, dynamic assignment methods are described in Section 5.
MNは、モビリティサーバの領域が発見されるのを知っているかもしれません。 MNはまた、使用するモビリティサーバのアドレスを事前に構成することができます。 MNは、照会するのか、レルム/モビリティサーバ知らない場合には、動的な割り当て方法は、第5節で説明されています。
The discovery of the Mobility Server (and the related configuration at MIHF level) is required to bind two MIHF peers (e.g., MN and Mobility Server) with their respective IP addresses. Discovery MUST be executed in the following conditions:
移動性サーバの発見（及びMIHFレベルでの関連の構成）は、それぞれのIPアドレスを持つ2つのMIHFピア（例えば、MN及びモビリティサーバ）に結合することが要求されます。ディスカバリーは、以下の条件で実行する必要があります。
o Bootstrapping: upon successful Layer 2 network attachment, the MN MAY be required to use DHCP for address configuration. These procedures can carry the required information for MoS configuration in specific DHCP options.
Oブートストラップ：成功したレイヤ2ネットワーク接続時に、MNは、アドレスの設定にDHCPを使用するために必要な場合があります。これらの手順は、特定のDHCPオプションのMOS構成のために必要な情報を伝えることができます。
o If the MN does not receive MoS information during network attachment and the MN does not have a pre-configured Mobility Server, it MUST run a discovery procedure upon initial IP address configuration.
MNは、ネットワーク接続の際のMoS情報を受信しないと、MNは、事前に設定モビリティサーバを持っていない場合は、O、それは最初のIPアドレス設定時に発見手順を実行する必要があります。
o If the MN changes its IP address (e.g., upon handover), it MUST refresh MIHF peer bindings (i.e., MIHF registration process). In case the Mobility Server used is not suitable anymore (e.g., too large RTT experienced), the MN MAY need to perform a new discovery procedure.
MNは、（ハンドオーバ時など、）そのIPアドレスを変更した場合、Oは、MIHFピアバインディング（すなわち、MIHF登録処理）をリフレッシュしなければなりません。場合に使用されるモビリティサーバは（例えば、大きすぎるRTTが経験）、MNは新しい発見手順を実行する必要があり、もはや適切ではありません。
o If the MN is a multi-homed device and it communicates with the same Mobility Server via different IP addresses, it MAY run discovery procedures if one of the IP addresses changes.
MNは、マルチホームのデバイスであり、それは別のIPアドレスを経由して同じモビリティサーバと通信する場合はIPのいずれかが変更に対処した場合、O、それは発見手順を実行することができます。
Once the MIHF peer has been discovered, MIH information can be exchanged between MIH peers over a transport protocol such as UDP or TCP. The usage of transport protocols is described in Section 6 and packing of the MIH messages does not require extra framing since the MIH protocol defined in [IEEE80221] already contains a length field.
MIHFピアが発見されたら、MIH情報は、UDPやTCPなどのトランスポートプロトコルを介してMIHピア間で交換することができます。トランスポートプロトコルの使用は、[IEEE80221]で定義されるMIHプロトコルが既に長さフィールドが含まれているため、余分なフレーミングを必要としないMIHメッセージのセクション6及び包装に記載されています。
Figure 5 depicts the MSFD reference model and its components within a node. The topmost layer is the MIHF user. This set of applications consists of one or more MIH clients that are responsible for operations such as generating query and response, processing Layer 2 triggers as part of the ES, and initiating and carrying out handover operations as part of the CS. Beneath the MIHF user is the MIHF itself. This function is responsible for MoS discovery, as well as creating, maintaining, modifying, and destroying MIH signaling associations with other MIHFs located in MIH peer nodes. Below the MIHF are various transport-layer protocols as well as address discovery functions.
図5は、MSFD参照モデルとノード内の構成要素を示します。最上層は、MIHFユーザです。アプリケーションのこのセットは、このようなESの一部としてクエリと応答、処理レイヤ2つのトリガーを生成し、CSの一部として開始し、ハンドオーバ動作を実行するなどの操作を担当している1つの以上のMIHクライアントで構成されています。 MIHFユーザの下MIHFそのものです。この関数は、MOS発見のために責任がある、ならびに、作成、維持、変更、およびMIHピア・ノードに位置する他のMIHFsとMIHシグナリングアソシエーションを破壊します。 MIHFの下には、さまざまなトランスポート層プロトコルだけでなく、アドレス検出機能があります。
+--------------------------+
| MIHF User |
+--------------------------+
||
+--------------------------+
| MIHF |
+--------------------------+
|| || ||
|| +------+ +-----+
|| | DHCP | | DNS |
|| +------+ +-----+
|| || ||
+--------------------------+
| TCP/UDP |
+--------------------------+
Figure 5: MN Stack
図5：MNスタック
The MIHF relies on the services provided by TCP and UDP for transporting MIH messages, and relies on DHCP and DNS for peer discovery. In cases where the peer MIHF IP address is not pre-configured, the source MIHF needs to discover it either via DHCP or DNS as described in Section 5. Once the peer MIHF is discovered, the MIHF must exchange messages with its peer over either UDP or TCP. Specific recommendations regarding the choice of transport protocols are provided in Section 6.
MIHFは、MIHメッセージを搬送するためのTCPおよびUDPが提供するサービスに依存し、ピア発見のためのDHCPとDNSに依存しています。ピアMIHF IPアドレスが事前に設定されていない場合には、MIHFは、5節で説明したように、ピアMIHFが発見された後のいずれかDHCPやDNS経由でそれを発見する必要があるソースは、MIHFはUDPのいずれかを介してそのピアとメッセージを交換しなければなりませんまたはTCP。トランスポートプロトコルの選択に関する具体的な提言は、第6節で提供されています。
There are no security features currently defined as part of the MIH protocol level. However, security can be provided either at the transport or IP layer where it is necessary. Section 8 provides guidelines and recommendations for security.
現在、MIHプロトコルレベルの一部として定義されたセキュリティ機能はありません。しかし、セキュリティはどちらか、それが必要であるトランスポートまたはIPレイヤで提供することができます。第8章では、セキュリティのためのガイドラインと推奨事項を提供します。
MIHFID is required to uniquely identify the MIHF end points for delivering the mobility services (MoS). Thus an MIHF identifier needs to be unique within a domain where mobility services are provided and independent of the configured IP address(es). An MIHFID MUST be represented either in the form of an FQDN [RFC2181] or NAI [RFC4282]. An MIHFID can be pre-configured or discovered through the discovery methods described in Section 5.
MIHFIDを一意にモビリティサービス（MOS）を送達するためのMIHFエンドポイントを識別するために必要とされます。したがってMIHF識別子は、モビリティサービスが提供され、設定されたIPアドレス（複数可）から独立しているドメイン内で一意である必要があります。 MIHFIDはFQDN [RFC2181]またはNAI [RFC4282]の形のいずれかで表現されなければなりません。 MIHFID部5に記載の検出方法を介して予め設定されるか、または発見することができます。
The MoS discovery method depends on whether the MN attempts to discover a Mobility Server in the home network, in the visited network, or in a third-party remote network that is neither the home network nor the visited network. In the case where the MN already has a Mobility Server address pre-configured, it is not necessary to run the discovery procedure. If the MN does not have pre-configured Mobility Server, the following procedure applies.
MoS発見方法は、MNが訪問先ネットワークで、またはホームネットワークや訪問先ネットワークでもないサードパーティ製のリモートネットワークでは、ホームネットワーク内のモビリティサーバを発見しようとするかどうかに依存します。 MNは、すでに事前設定モビリティサーバのアドレスを持っている場合は、発見手順を実行する必要はありません。 MNは、モビリティサーバを事前に設定されていない場合は、以下の手順が適用されます。
In the case where a Mobility Server is provided locally (scenarios S1 and S2), the discovery techniques described in [RFC5678] and [RFC5679] are both applicable as described in Sections 5.1 and 5.2.
セクション5.1および5.2に記載したように移動性サーバは、（シナリオS1及びS2）局所的に設けられている場合には、[RFC5678]及び[RFC5679]に記載発見技術の両方に適用可能です。
In the case where a Mobility Server is located in the home network while the MN is in the visited network (scenario S4), the DNS-based discovery described in [RFC5679] is applicable.
MNが訪問先ネットワーク（シナリオS4）にある間に移動性サーバがホームネットワークに位置する場合には、[RFC5679]に記載のDNSベースの検出を適用することができます。
In the case where a Mobility Server is located in a third-party network that is different from the current visited network (scenario S3), only the DNS-based discovery method described in [RFC5679] is applicable.
移動性サーバは、現在の訪問先ネットワーク（シナリオS3）とは異なるサードパーティのネットワークに位置する場合には、[RFC5679]で説明のみDNSベースの検出法が適用可能です。
It should be noted that authorization of an MN to use a specific Mobility Server is neither in scope of this document nor is currently specified in [IEEE80221]. We further assume all devices can access discovered MoS. In case future deployments will implement authorization policies, the mobile nodes should fall back to other learned MoS if authorization is denied.
特定のモビリティServerを使用するMNの認証がどちらも、この文書の範囲内であることも、[IEEE80221]で現在指定されていることに留意すべきです。我々はさらに、すべてのデバイスが発見されたのMoSにアクセスできると仮定します。認証が拒否された場合場合には将来の展開は、認可ポリシーを実装する、モバイルノードは、他の学びのMoSにフォールバックする必要があります。
5.1. MoS Discovery When MN and MoSh Are in the Home Network (Scenario S1)
5.1. MoSディスカバリーMNとモッシュは、ホームネットワーク（シナリオS1）にあるとき
To discover a Mobility Server in the home network, the MN SHOULD use the DNS-based MoS discovery method described in [RFC5679]. In order to use that mechanism, the MN MUST have its home domain pre-configured (i.e., subscription is tied to a network). The DNS query option is shown in Figure 6a. Alternatively, the MN MAY use the DHCP options for MoS discovery [RFC5678] as shown in Figure 6b (in some deployments, a DHCP relay may not be present).
ホームネットワーク内のモビリティサーバを検出するには、MNは、[RFC5679]で説明DNSベースのMoS発見方法を使用すべきです。そのメカニズムを使用するためには、MNは、（すなわち、サブスクリプションがネットワークに接続されてい）そのホームドメインがあらかじめ設定しておく必要があります。 DNSクエリオプションは図6aに示されています。代替的に、MNは、（いくつかの展開では、DHCPリレーが存在しなくてもよい）は、図6bに示すように、MOS発見[RFC5678]のためのDHCPオプションを使用するかもしれません。
(a) +-------+
+----+ |Domain |
| MN |-------->|Name |
+----+ |Server |
MN@example.org +-------+
(b)
+-----+ +------+
+----+ | | |DHCP |
| MN |<----->| DHCP|<---->|Server|
+----+ |Relay| | |
+-----+ +------+
Figure 6: MOS Discovery (a) Using DNS Query, (b) Using DHCP Option
図6：MOSディスカバリー（a）のDNSクエリ、（b）は使用してDHCPオプションを使用しました
5.2. MoS Discovery When MN and MoSv Both Are in Visited Network (Scenario S2)
5.2. MoSディスカバリーMNとMOSVの両方が訪問先ネットワーク（シナリオS2）にあるとき
To discover a Mobility Server in the visited network, the MN SHOULD attempt to use the DHCP options for MoS discovery [RFC5678] as shown in Figure 7.
図7に示すように、訪問先ネットワークにおけるモビリティサーバを検出するには、MNは、MOS発見[RFC5678]のためのDHCPオプションを使用しようとすべきです。
+-----+ +------+
+----+ | | |DHCP |
| MN |<----->| DHCP|<---->|Server|
+----+ |Relay| | |
+-----+ +------+
Figure 7: MoS Discovery Using DHCP Options
図7：DHCPオプションを用いたMOSディスカバリー
5.3. MoS Discovery When MIH Services Are in a Third-Party Remote Network (Scenario S3)
5.3. MoSディスカバリーMIHサービスは、サードパーティのリモートネットワーク（シナリオS3）にあるとき
To discover a Mobility Server in a remote network other than home network, the MN MUST use the DNS-based MoS discovery method described in [RFC5679]. The MN MUST first learn the domain name of the network containing the MoS it is searching for. The MN can query its current Mobility Server to find out the domain name of a specific network or the domain name of a network at a specific location (as in Figure 8a). IEEE 802.21 defines information elements such as OPERATOR ID and SERVICE PROVIDER ID that can be a domain name. An IS query can provide this information, see [IEEE80221].
ホームネットワーク以外のリモートネットワークにおけるモビリティサーバを検出するには、MNは、[RFC5679]で説明DNSベースのMoS発見方法を使用しなければなりません。 MNは、まず、それが探しているのMoSを含むネットワークのドメイン名を学ばなければなりません。 MNは、（図8aのように）特定のネットワークまたは特定の場所でのネットワークのドメイン名のドメイン名を見つけるために、現在のモビリティサーバを照会することができます。 IEEE 802.21は、オペレータIDとドメイン名とすることができるサービスプロバイダIDなどの情報要素を定義します。 ISのクエリは、[IEEE80221]を参照、この情報を提供することができます。
Alternatively, the MN MAY query a Mobility Server previously known to learn the domain name of the desired network. Finally, the MN MUST use DNS-based discovery mechanisms to find a Mobility Server in the remote network as in Figure 8b. It should be noted that step b can only be performed upon obtaining the domain name of the remote network.
また、MNは、目的のネットワークのドメイン名を学ぶために以前から知られているモビリティサーバに照会することができます。最後に、MNは、図8bのように、リモートネットワーク内のモビリティサーバを見つけるために、DNSベースの検出メカニズムを使用しなければなりません。ステップbのみリモートネットワークのドメイン名を取得する際に行うことができることに留意すべきです。
(a)
+------------+
+----+ | |
| | |Information |
| MN |-------->| Server |
| | |(previously |
+----+ |discovered) |
+------------+
(b)
+-------+
+----+ |Domain |
| MN |-------->|Name |
+----+ |Server |
MN@example.org +-------+
Figure 8: MOS Discovery Using (a) IS Query to a Known IS Server, (b) DNS Query
図8：MOSディスカバリー（A）を使用すると、既知のクエリですが（b）のDNSクエリ、サーバであり、
5.4. MoS Discovery When the MN Is in a Visited Network and Services Are at the Home Network (Scenario S4)
5.4. MoSディスカバリーMNが訪問先ネットワーク内にあり、サービスは、ホームネットワークにある場合（シナリオS4）
To discover a Mobility Server in the visited network when MIH services are provided by the home network, the DNS-based discovery method described in [RFC5679] is applicable. To discover the Mobility Server at home while in a visited network using DNS, the MN SHOULD use the procedures described in Section 5.1.
MIHサービスがホームネットワークによって提供されたときに訪問先ネットワークにおけるモビリティサーバを検出するには、[RFC5679]で説明DNSベースの検出方法が適用されます。訪問先ネットワークでDNSを使用しながら、自宅でモビリティサーバを検出するには、MNは、セクション5.1で説明した手順を使用すべきです。
Once the MoS have been discovered, MIH peers run a capability discovery and subscription procedure as specified in [IEEE80221]. MIH peers MAY exchange information over TCP, UDP, or any other transport supported by both the server and the client. The client MAY use the DNS discovery mechanism to discover which transport protocols are supported by the server in addition to TCP and UDP that are recommended in this document. While either protocol can provide the basic transport functionality required, there are performance trade-offs and unique characteristics associated with each that need to be considered in the context of the MIH services for different network loss and congestion conditions. The objectives of this section are to discuss these trade-offs for different MIH settings such as the MIH message size and rate, and the retransmission parameters. In addition, factors such as NAT traversal are also discussed. Given the reliability requirements for the MIH transport, it is assumed in this discussion that the MIH ACK mechanism is to be used in conjunction with UDP, while it MUST NOT be used with TCP since TCP includes acknowledgement and retransmission functionality.
MOSトランジスタ発見されたら、[IEEE80221]で指定され、MIHピアは、能力発見と加入手続きを実行します。 MIHピアはTCP、UDP、またはサーバーとクライアントの両方でサポートされている任意の他のトランスポートを介して情報を交換することができます。クライアントは、この文書で推奨されているTCPおよびUDPに加えて、サーバーによってサポートされているトランスポートプロトコルを発見するためにDNSディスカバリメカニズムを使用するかもしれません。プロトコルが必要な基本的なトランスポート機能を提供するかが、異なるネットワーク損失と混雑状態に対してMIHサービスの文脈において考慮される必要がある性能のトレードオフとそれぞれに関連する固有の特性があります。このセクションの目的は、このようなMIHメッセージのサイズとレート、および再送パラメータとして異なるMIHの設定のためにこれらのトレードオフを議論することです。加えて、そのようなNATトラバーサルなどの要因についても議論されています。 MIH輸送のための信頼性要件を考えると、TCPが確認応答および再送信機能を備えているので、それはTCPで使用してはいけませんしながら、MIH ACKメカニズムは、UDPと一緒に使用されることを、この議論で想定されます。
Although the MIH message size varies widely from about 30 bytes (for a capability discovery request) to around 65000 bytes (for an IS MIH_Get_Information response primitive), a typical MIH message size for the ES or CS ranges between 50 to 100 bytes [IEEE80221]. Thus, considering the effects of the MIH message size on the performance of the transport protocol brings us to discussing two main issues, related to fragmentation of long messages in the context of UDP and the concatenation of short messages in the context of TCP.
MIHメッセージのサイズが（能力発見要求に対して）約30バイトから約65000バイト（プリミティブIS MIH_Get_Information応答のため）に広く変化するが、ES又はCSのための典型的なMIHメッセージのサイズが50〜100バイト[IEEE80221]の間の範囲であります。このように、トランスポートプロトコルのパフォーマンス上のMIHメッセージサイズの影響を考慮すると、UDPのコンテキストとTCPの文脈におけるショートメッセージの連結に長いメッセージの断片化に関連する2つの主な問題を、議論に私たちをもたらします。
Since transporting long MIH messages may require fragmentation that is not available in UDP, if MIH is using UDP a limit MUST be set on the size of the MIH message based on the path MTU to destination (or the Minimum MTU where PMTU is not implemented). The Minimum MTU depends on the IP version used for transmission, and is the lesser of the first hop MTU, and 576 or 1280 bytes for IPv4 [RFC1122] or for IPv6 [RFC2460], respectively, although applications may reduce these values to guard against the presence of tunnels.
長いMIHメッセージを搬送するUDPで利用可能でないフラグメンテーションを必要とするかもしれないので、MIHは、UDPを使用している場合、制限は目的地までの経路MTU（またはPMTUが実装されていない最小のMTU）に基づいて、MIHメッセージのサイズに設定しなければなりません。アプリケーションを防ぐために、これらの値を減少させることができるものの、最小のMTUは、送信のために使用されるIPバージョンに依存し、最初のホップのMTUのうちの小さい方である、とIPv4 [RFC1122]またはそれぞれのIPv6 [RFC2460]のために576の又は1280バイトトンネルの存在。
According to [IEEE80221], when an MIH message is sent using an L3 or higher-layer transport, L3 takes care of any fragmentation issue and the MIH protocol does not handle fragmentation in such cases. Thus, MIH layer fragmentation MUST NOT be used together with IP layer fragmentation and MUST not be used when MIH packets are carried over TCP.
【IEEE80221]によれば、MIHメッセージはL3又は上位層トランスポートを使用して送信された場合、L3は、任意の断片化の問題の世話をし、MIHプロトコルは、このような場合にフラグメンテーションを処理しません。このように、MIH層断片化は、IP層断片化と一緒に使用してはいけませんし、MIHパケットがTCP上で実行されたときに使用することはできません。
The loss of an IP fragment leads to the retransmission of an entire MIH message, which in turn leads to poor end-to-end delay performance in addition to wasted bandwidth. Additional recommendations in [RFC5405] apply for limiting the size of the MIH message when using UDP and assuming IP layer fragmentation. In terms of dealing with short messages, TCP has the capability to concatenate very short messages in order to reduce the overall bandwidth overhead. However, this reduced overhead comes at the cost of additional delay to complete an MIH transaction, which may not be acceptable for CS and ES. Note also that TCP is a stream-oriented protocol and measures data flow in terms of bytes, not messages. Thus, it is possible to split messages across multiple TCP segments if they are long enough. Even short messages can be split across two segments. This can also cause unacceptable delays, especially if the link quality is severely degraded as is likely to happen when the MN is exiting a wireless access coverage area. The use of the TCP_NODELAY option can alleviate this problem by triggering transmission of a segment less than the SMSS. (It should be noted that [RFC4960] addresses both of these problems, but discussion of SCTP is omitted here, as it is generally not used for the mobility services discussed in this document.)
IPフラグメントの損失は、次に帯域幅の浪費に加えて、乏しいエンドツーエンド遅延性能につながる全体のMIHメッセージの再送につながります。 [RFC5405]での追加の推奨事項は、UDPを使用するときにMIHメッセージのサイズを制限し、IPレイヤフラグメンテーションを想定するための適用します。短いメッセージを扱うという点では、TCPは、全体的な帯域幅のオーバーヘッドを減らすために、非常に短いメッセージを連結する機能があります。しかし、この減少オーバーヘッドはCSとESのために許容できない場合がありMIHトランザクションを完了するために追加の遅延を犠牲にしています。注意はまた、TCPは、ストリーム指向のプロトコルであり、バイトではなく、メッセージの観点でデータフローを測定します。このように、彼らが十分な長さであれば、複数のTCPセグメント間でメッセージを分割することが可能です。でも、短いメッセージは二つのセグメントに分割することができます。これはまた、MNは、無線アクセスサービスエリアを終了するときに発生する可能性があるとして、リンク品質が著しく低下した場合は特に、容認できない遅延を引き起こす可能性があります。 TCP_NODELAYオプションの使用は、以下SMSSよりセグメントの送信をトリガすることによって、この問題を軽減することができます。 （[RFC4960]は、これらの問題の両方に対処しますが、それは一般的に、この文書で説明するモビリティサービスのために使用されていないとして、SCTPの議論は、ここでは省略されていることに留意すべきです。）
The frequency of MIH messages varies according to the MIH service type. It is expected that CS/ES messages arrive at a rate of one in hundreds of milliseconds in order to capture quick changes in the environment and/or process handover commands. On the other hand, IS messages are exchanged mainly every time a new network is visited, which may be in order of hours or days. Therefore, a burst of either short CS/ES messages or long IS message exchanges (in the case where multiple MIH nodes request information) may lead to network congestion. While the built-in rate-limiting controls available in TCP may be well suited for dealing with these congestion conditions, this may result in large transmission delays that may be unacceptable for the timely delivery of ES or CS messages. On the other hand, if UDP is used, a rate-limiting effect similar to the one obtained with TCP SHOULD be obtained by adequately adjusting the parameters of a token bucket regulator as defined in the MIH specifications [IEEE80221]. Recommendations for token bucket parameter settings are as follows:
MIHメッセージの頻度は、MIHサービスの種類に応じて変化します。 CS / ESメッセージが速い環境の変化および/またはプロセスのハンドオーバコマンドをキャプチャするために数百ミリ秒の1の割合で到着することが予想されます。一方、メッセージは主に数時間または数日間の順であってもよく、新たなネットワークが訪問するたびに、交換されています。したがって、短いCS / ESメッセージまたは（複数MIHノードが情報を要求する場合）長であるメッセージ交換のいずれかのバーストは、ネットワークの輻輳をもたらす可能性があります。 TCPで利用可能な内蔵のレート制限コントロールはこれらの混雑状況に対処するための十分適しているかもしれないが、これはESやCSメッセージのタイムリーな配信のために容認できない大きな伝送遅延をもたらすことができます。 UDPが使用されている一方、TCPを用いて得られたものと同様の律速効果が十分MIH仕様[IEEE80221]で定義されるようにトークン・バケット・レギュレータのパラメータを調整することによって得られるはずです。次のようにトークンバケットパラメータ設定のための推奨事項は、次のとおりです。
o If the MIHF knows the RTT (e.g., based on the request/response MIH protocol exchange between two MIH peers), the rate can be based upon this as specified in [IEEE80221].
MIHFは、RTT（例えば、2つのMIHピア間で要求/応答MIHプロトコル交換に基づく）を知っている場合[IEEE80221]で指定されるように、O、速度がこの基づくことができます。
o If not, then on average it SHOULD NOT send more than one UDP message every 3 seconds.
ない場合は、O、その後、平均的には、複数のUDPメッセージごとに3秒を送るべきではありません。
For TCP, the retransmission timeout is adjusted according to the measured RTT. However due to the exponential backoff mechanism, the delay associated with retransmission timeouts may increase significantly with increased packet loss.
TCPは、再送タイムアウトは、測定されたRTTに応じて調整されます。しかしながらによる指数バックオフ機構に、再送タイムアウトに関連する遅延が増加し、パケット損失に有意に増加し得ます。
If UDP is being used to carry MIH messages, MIH MUST use MIH ACKs. An MIH message is retransmitted if its corresponding MIH ACK is not received by the generating node within a timeout interval set by the MIHF. The maximum number of retransmissions is configurable and the value of the retransmission timer is computed according to the algorithm defined in [RFC2988]. The default maximum number of
UDPは、MIHメッセージを運ぶために使用されている場合、MIHは、MIH ACKを使用しなければなりません。その対応するMIH ACKは、MIHFによって設定されたタイムアウト間隔内に発生ノードによって受信されない場合、MIHメッセージが再送されます。再送の最大数は設定可能であり、再送タイマの値は、[RFC2988]で定義されたアルゴリズムに従って計算されます。のデフォルトの最大数
retransmissions is set to 2 and the initial retransmission timer (TMO) is set to 3s when RTT is not known. The maximum TMO is set to 30s.
再送は2に設定され、RTTが知られていないときの初期再送タイマ（TMO）は3秒に設定されています。最大TMOは、30代に設定されています。
There are no known issues for NAT traversal when using TCP. The default connection timeout of 2 hours 4 minutes [RFC5382] (assuming a 2-hour TCP keep-alive) is considered adequate for MIH transport purposes. However, issues with NAT traversal using UDP are documented in [RFC5405]. Communication failures are experienced when middleboxes destroy the per-flow state associated with an application session during periods when the application does not exchange any UDP traffic. Hence, communication between the MN and the Mobility Server SHOULD be able to gracefully handle such failures and implement mechanisms to re-establish their UDP sessions. In addition and in order to avoid such failures, MIH messages MAY be sent periodically, similarly to keep-alive messages, in an attempt to refresh middlebox state. As [RFC4787] requires a minimum state timeout of 2 minutes or more, MIH messages using UDP as transport SHOULD be sent once every 2 minutes. Re-registration or event indication messages as defined in [IEEE80221] MAY be used for this purpose.
TCPを使用するときにNATトラバーサルのための既知の問題はありません。 2時間のデフォルトの接続タイムアウト4分[RFC5382]（想定2時間のTCPキープアライブ）MIH輸送目的のために適切であると考えられます。しかし、UDPを使用してNATトラバーサルの問題は、[RFC5405]に記載されています。ミドルボックスは、アプリケーションがUDPトラフィックを交換しない期間中のアプリケーションセッションに関連付けられたフローごとの状態を破壊したときに通信障害が経験しています。したがって、MNとモビリティサーバ間の通信は、優雅に、このような障害に対処し、そのUDPセッションを再確立するためのメカニズムを実装することができるべきです。さらに、及びそのような失敗を避けるために、MIHメッセージは、同様に、キープアライブするメッセージを、ミドル状態をリフレッシュしようとする試みには、定期的に送信されるかもしれません。 [RFC4787]は2分以上の最小の状態のタイムアウトを必要とする、トランスポートとしてUDPを使用してMIHメッセージは一度2分ごとに送信されるべきです。 【IEEE80221]で定義された再登録またはイベント通知メッセージとしてこの目的に使用することができます。
The ES and CS messages are small in nature and have tight latency requirements. On the other hand, IS messages are more resilient in terms of latency constraints, and some long IS messages could exceed the MTU of the path to the destination. TCP SHOULD be used as the default transport for all messages. However, UDP in combination with MIH acknowledgement SHOULD be used for transporting ES and CS messages that are shorter than or equal to the path MTU as described in Section 6.1.
ESとCSのメッセージは、本質的に小さく、厳しい待ち時間要件を持っています。一方、メッセージは、レイテンシ制約の面で、より弾力性のある、そして長いいくつかのメッセージは、宛先へのパスのMTUを超える可能性です。 TCPは、すべてのメッセージのデフォルトのトランスポートとして使用する必要があります。しかし、MIH肯定応答との組み合わせでUDPは、より短いか、6.1節で説明したように、パスMTUに等しいESとCSメッセージを輸送するために使用されるべきです。
For both UDP and TCP cases, if a port number is not explicitly assigned (e.g., by the DNS SRV), MIH messages sent over UDP, TCP, or other supported transport MUST use the default port number defined in Section 9 for that particular transport.
ポート番号を明示的に（例えば、DNSのSRVによって）割り当てられていない場合の両方のUDPとTCPの場合については、MIHメッセージは、その特定の輸送については、セクション9で定義されたデフォルトのポート番号を使用しなければならないUDP、TCP、またはその他のサポートされているトランスポートを介して送信されます。
A Mobility Server MUST support both UDP and TCP for MIH transport and the MN MUST support TCP. Additionally, the server and MN MAY support additional transport mechanisms. The MN MAY use the procedures defined in [RFC5679] to discover additional transport protocols supported by the server (e.g., SCTP).
モビリティServerは、MIH輸送のためにUDPとTCPの両方をサポートしなければならないし、MNは、TCPをサポートしなければなりません。また、サーバとMNは、追加のトランスポート・メカニズムをサポートするかもしれません。 MNは、サーバ（例えば、SCTP）によってサポートされる追加のトランスポートプロトコルを発見するために[RFC5679]で定義された手順を使用するかもしれません。
Figure 9 gives an example operation flow between MIHF peers when an MIH user requests an IS and both the MN and the Mobility Server are in the MN's home network. DHCP is used for Mobility Services (MoS) discovery, and TCP is used for establishing a transport connection to carry the IS messages. When the Mobility Server is not pre-configured, the MIH user needs to discover the IP address of the Mobility Server to communicate with the remote MIHF. Therefore, the MIH user sends a discovery request message to the local MIHF as defined in [IEEE80221].
MIHユーザであるとMNとモビリティServerの両方が、MNのホームネットワーク内にある要求したとき、図9は、MIHFピア間の例の動作フローを提供します。 DHCPは、モビリティサービス（MOS）の発見のために使用され、TCPは、ISのメッセージを運ぶためにトランスポート接続を確立するために使用されます。モビリティサーバが事前に設定されていない場合は、MIHユーザは、リモートMIHFと通信するためにモビリティサーバのIPアドレスを発見する必要があります。したがって、MIHユーザは[IEEE80221]で定義されるように、ローカルMIHFにディスカバリ要求メッセージを送信します。
In this example (one could draw similar mechanisms with DHCPv6), we assume that MoS discovery is performed before a transport connection is established with the remote MIHF, and the DHCP client process is invoked via some internal APIs. The DHCP client sends a DHCP INFORM message according to standard DHCP and with the MoS option as defined in [RFC5678]. The DHCP server replies via a DHCP ACK message with the IP address of the Mobility Server. The Mobility Server address is then passed to the MIHF locally via some internal APIs. The MIHF generates the discovery response message and passes it on to the corresponding MIH user. The MIH user generates an IS query addressed to the remote Mobility Server. The MIHF invokes the underlying TCP client, which establishes a transport connection with the remote peer. Once the transport connection is established, the MIHF sends the IS query via an MIH protocol REQUEST message. The message and query arrive at the destination MIHF and MIH user, respectively. The Mobility Server MIH user responds to the corresponding IS query and the Mobility Server MIHF sends the IS response via an MIH protocol RESPONSE message. The message arrives at the source MIHF, which passes the IS response on to the corresponding MIH user.
この例では、（1がDHCPv6のと同様のメカニズムを描くことができ）、我々はトランスポート接続がリモートMIHFで確立され、DHCPクライアント・プロセスは、いくつかの内部APIを経由して呼び出される前のMoS検出が実行されていることを前提としています。 DHCPクライアントがDHCPは、[RFC5678]で定義されている標準のDHCPにとMOSオプションで応じたメッセージを通知送信します。 DHCPサーバは、モビリティサーバのIPアドレスをDHCP ACKメッセージを介して返信します。モビリティサーバのアドレスは、その後、いくつかの内部APIを経由して、ローカルMIHFに渡されます。 MIHFは、ディスカバリ応答メッセージを生成し、対応するMIHユーザにそれを渡します。 MIHユーザは、ISクエリがリモートモビリティサーバ宛生成します。 MIHFは、リモートピアとのトランスポート接続を確立し、基礎となるTCPクライアントを起動します。トランスポート接続が確立されると、MIHFは、MIHプロトコルREQUESTメッセージを介してISクエリを送信します。メッセージとクエリは、それぞれ、先のMIHFとMIHユーザに到達します。モビリティサーバMIHユーザは、対応する応答クエリISとモビリティサーバMIHFは、MIHプロトコル応答メッセージを介してIS応答を送信します。メッセージは、対応するMIHユーザにオンになっている応答を渡すソースMIHF、に到達します。
MN MoS
|===================================| |======| |===================|
+ ---------+ +---------+
| MIH USER | +------+ +------+ +------+ +------+ | MIH USER|
| +------+ | | TCP | |DHCP | |DHCP | | TCP | | +------+|
| | MIHF | | |Client| |Client| |Server| |Server| | | MIHF ||
+----------+ +------+ +------+ +------+ +------++----------+
| | | | | |
MIH Discovery | | | | |
Request | | | | |
| | | | | |
|Invoke DHCP Client | | | |
|(Internal process with MoS)|DHCP INFORM| | |
|==========================>|==========>| | |
| | | | | |
| Inform Mobility Server | DHCP ACK | | |
| Address |<==========| | |
|<==========================| | | |
| (internal process) | | | |
| | | | | |
MIH Discovery | | | | |
Response | | | | |
| | | | | |
IS Query | | | | |
MIH User-> MIHF | | | | |
| | | | | |
|Invoke TCP Client| | | | |
|================>| TCP connection established | |
Internal process |<=============================>| |
| | | | | |
| IS QUERY REQUEST (via MIH protocol) |
|===========================================================>|
| | | | | IS QUERY|
| | | | | REQUEST|
| | | | MIHF-> MIH User |
| | | | | QUERY|
| | | | | RESPONSE|
| | | | MIHF <-MIH User |
| | | | | |
| | IS QUERY RESPONSE (via MIH protocol) |
|<===========================================================|
| | | | | |
IS RESPONSE | | | | |
MIH User <-MIHF | | | | |
| | | | | |
Figure 9: Example Flow of Operation Involving MIH User
図9：MIHユーザを伴う動作例の流れ
There are two components to the security considerations: MoS discovery and MIH transport. For MoS discovery, DHCP and DNS recommendations are hereby provided per IETF guidelines. For MIH transport, we describe the security threats and expect that the system deployment will have means to mitigate such threats when sensitive information is being exchanged between the mobile node and Mobility Server. Since IEEE 802.21 base specification does not provide MIH protocol level security, it is assumed that either lower layer security (e.g., link layer) or overall system-specific (e.g., proprietary) security solutions are available. The present document does not provide any guidelines in this regard. It is stressed that the IEEE 802.21a Task Group has recently started work on MIH security issues that may provide some solution in this area. Finally, authorization of an MN to use a specific Mobility Server, as stated in Section 5, is neither in scope of this document nor is currently specified in [IEEE80221].
MoSの発見とMIH輸送：セキュリティ上の考慮事項には、2つのコンポーネントがあります。 MOに発見、DHCPとDNSの勧告は、ここにIETFガイドラインごとに提供されています。 MIH輸送のために、我々は、セキュリティ上の脅威を説明し、システムの導入は、機密情報がモバイルノードとモビリティサーバ間で交換されているときに、このような脅威を軽減するための手段を持っていることを期待しています。 IEEE 802.21ベースの仕様では、MIHプロトコルレベルのセキュリティを提供しないので、それは下位層セキュリティ（例えば、リンク層）または全体的なシステム固有のいずれかのものとする（例えば、独自の）セキュリティソリューションが利用可能です。本書は、この点で任意のガイドラインを提供していません。 IEEE 802.21aタスクグループは、この分野でいくつかのソリューションを提供することができるMIHのセキュリティ問題に関する作業を最近開始したことを強調しています。最後に、5章で述べたように、特定のモビリティServerを使用するMNの許可は、どちらもこの文書の範囲であるにも[IEEE80221]で現在指定されています。
There are a number of security issues that need to be taken into account during node discovery. In the case where DHCP is used for node discovery and authentication of the source and content of DHCP messages is required, network administrators SHOULD use the DHCP authentication option described in [RFC3118], where available, or rely upon link layer security. [RFC3118] provides mechanisms for both entity authentication and message authentication. In the case where the DHCP authentication mechanism is not available, administrators may need to rely upon the underlying link layer security. In such cases, the link between the DHCP client and Layer 2 termination point may be protected, but the DHCP message source and its messages cannot be authenticated or the integrity of the latter checked unless there exits a security binding between link layer and DHCP layer.
ノード検出の際に考慮する必要があるセキュリティ上の問題がいくつかあります。 DHCPは、DHCPメッセージのソースとコンテンツのノード発見および認証に使用する場合に必要とされる、ネットワーク管理者は、利用可能な[RFC3118]に記載のDHCP認証オプションを、使用、またはリンク層セキュリティに依存すべきです。 [RFC3118]は、エンティティ認証とメッセージ認証の両方のためのメカニズムを提供します。 DHCP認証メカニズムが利用できない場合は、管理者は、基礎となるリンクレイヤのセキュリティに頼る必要があるかもしれません。このような場合には、DHCPクライアントおよびレイヤ2終端点間のリンクは保護されていてもよいが、リンク層およびDHCP層の間に結合セキュリティが終了しない限り、DHCPメッセージの送信元とそのメッセージが認証できないか、後者の整合性をチェックします。
In the case where DNS is used for discovering MoS, fake DNS requests and responses may cause denial of service (DoS) and the inability of the MN to perform a proper handover, respectively. Where networks are exposed to such DoS, it is RECOMMENDED that DNS service providers use the Domain Name System Security Extensions (DNSSEC) as described in [RFC4033]. Readers may also refer to [RFC4641] to consider the aspects of DNSSEC operational practices.
DNSは、MOSを発見するために使用される場合には、偽のDNS要求と応答は、それぞれ、サービス拒否（DOS）及び適切なハンドオーバを実行するためのMNの不能を引き起こす可能性があります。ネットワークは、このようなDoS攻撃にさらされている場合、[RFC4033]で説明したようにDNSサービスプロバイダは、ドメインネームシステムセキュリティ拡張（DNSSEC）を使用することをお勧めします。読者はまた、DNSSEC運用実務の側面を考慮するために、[RFC4641]を参照してもよいです。
The communication between an MN and a Mobility Server is exposed to a number of security threats: o Mobility Server identity spoofing. A fake Mobility Server could provide the MNs with bogus data and force them to select the wrong network or to make a wrong handover decision.
モビリティサーバの身元詐称O：MNとモビリティサーバ間の通信は、セキュリティ上の脅威の数にさらされています。偽のモビリティサーバは、偽のデータとのMNを提供し、間違ったネットワークを選択するか、間違ったハンドオーバ決定を行うためにそれらを強制することができます。
o Tampering. Tampering with the information provided by a Mobility Server may result in the MN making wrong network selection or handover decisions.
改ざんO。モビリティサーバによって提供された情報が改ざんされる間違ったネットワークの選択やハンドオーバ意思決定をMNになることがあります。
o Replay attack. Since Mobility Services as defined in [IEEE80221] support a 'PUSH model', they can send large amounts of data to the MNs whenever the Mobility Server thinks that the data is relevant for the MN. An attacker may intercept the data sent by the Mobility Server to the MNs and replay it at a later time, causing the MNs to make network selection or handover decisions that are not valid at that point in time.
Oリプレイ攻撃。モビリティサービス以来[IEEE80221]で定義されている「PUSHモデル」をサポートし、彼らはモビリティServerがデータをMNに関連することを考えている時はいつでものMNに大量のデータを送信することができます。攻撃者は、MNのにモビリティサーバーによって送信されたデータを傍受し、その時点で有効でないネットワーク選択やハンドオーバ意思決定を行うためのMNを引き起こして、後でそれを再生することがあります。
o Eavesdropping. By snooping the communication between an MN and a Mobility Server, an attacker may be able to trace a user's movement between networks or cells, or predict future movements, by inspecting handover service messages.
盗聴O。 MNとモビリティサーバ間の通信をスヌーピングすることにより、攻撃者は、ハンドオーバサービスメッセージを検査することで、ネットワークまたはセル間のユーザーの動きを追跡、または将来の動きを予測することができるかもしれません。
There are many deployment-specific system security solutions available, which can be used to countermeasure the above mentioned threats. For example, for the MoSh and MoSv scenarios (including roaming scenarios), link layer security may be sufficient to protect the communication between the MN and Mobility Server. This is a typical mobile operator environment where link layer security provides authentication, data confidentiality, and integrity. In other scenarios, such as the third-party MoS, link layer security solutions may not be sufficient to protect the communication path between the MN and the Mobility Server. The communication channel between MN and Mobility Server needs to be secured by other means.
上記の脅威を対策するために使用できる利用可能な多くの展開固有のシステム・セキュリティ・ソリューションは、あります。例えば、（ローミングシナリオを含む）モッシュとMOSVシナリオで、リンク層セキュリティは、MNとモビリティサーバ間の通信を保護するのに十分であってもよいです。これは、リンク層のセキュリティ認証、データの機密性、および完全性を提供し、一般的な携帯電話事業者の環境です。このようなサードパーティのMoSなどの他のシナリオでは、リンク・レイヤ・セキュリティソリューションは、MNとモビリティサーバの間の通信経路を保護するのに十分ではないかもしれません。 MNとモビリティサーバ間の通信チャネルは、他の手段で確保する必要があります。
The present document does not provide any specific guidelines about the way these security solutions should be deployed. However, if in the future the IEEE 802.21 Working Group amends the specification with MIH protocol level security or recommends the deployment scenarios, IETF may revisit the security considerations and recommend specific transport-layer security as appropriate.
本書は、これらのセキュリティソリューションが展開されるべき方法についての具体的なガイドラインを提供していません。将来的にはIEEE 802.21ワーキンググループは、MIHプロトコルレベルのセキュリティで仕様を修正または展開シナリオを推奨しています場合は、IETFは、セキュリティ上の考慮事項を再検討し、必要に応じて特定のトランスポート・レイヤ・セキュリティを勧告することができます。
This document registers the following TCP and UDP ports with IANA:
このドキュメントは、IANAで、次のTCPおよびUDPポートを登録します。
Keyword Decimal Description
-------- --------------- ------------
ieee-mih 4551/tcp MIH Services
ieee-mih 4551/udp MIH Services
The authors would like to thank Yoshihiro Ohba, David Griffith, Kevin Noll, Vijay Devarapalli, Patrick Stupar, and Sam Xia for their valuable comments, reviews, and fruitful discussions.
作者は彼らの貴重なコメント、レビュー、そして実りある議論を義弘大場、デビッド・グリフィス、ケビン・ノル、ビジェイDevarapalli、パトリックStupar、とサム夏に感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
"DNS仕様の明確化" [RFC2181]エルツ、R.とR.ブッシュ、RFC 2181、1997年7月。
[RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] Droms、R.、エド。、およびW. Arbaugh、エド。、 "DHCPメッセージの認証"、RFC 3118、2001年6月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315 、2003年7月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J.、およびP. Eronen、 "ネットワークアクセス識別子"、RFC 4282、2005年12月。
[RFC5678] Bajko, G. and S. Das, "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery", RFC 5678, December 2009.
[RFC5678] Bajko、G.とS.ダス、 "動的ホスト構成プロトコル（DHCPv4とDHCPv6の）IEEE 802.21モビリティサービス（MOS）の発見のためのオプション"、RFC 5678、2009年12月。
[RFC5679] Bajko, G., "Locating IEEE 802.21 Mobility Services Using DNS", RFC 5679, December 2009.
[RFC5679] Bajko、G.、 "DNSを使用したIEEE 802.21モビリティサービスの検索"、RFC 5679、2009年12月。
[IEEE80221] "IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services", IEEE LAN/MAN Std 802.21-2008, January 2009, http://www.ieee802.org/21/private/Published%20Spec/ 802.21-2008.pdf (access to the document requires membership).
[IEEE80221] "ローカルおよびメトロポリタンエリアネットワークのIEEE規格 - パート21：メディア独立ハンドオーバサービス"、IEEE LAN / MAN STD 802.21から2008、2009年1月、http://www.ieee802.org/21/private/Published% 20Spec / 802.21-2008.pdf（ドキュメントへのアクセスは、メンバーシップが必要です）。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]パクソン、V.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、2000年11月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006.
[RFC4641] Kolkman、O.とR. Gieben、 "DNSSEC運用・プラクティス"、RFC 4641、2006年9月。
[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F.、エド。、およびC.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC5164] Melia, T., Ed., "Mobility Services Transport: Problem Statement", RFC 5164, March 2008.
[RFC5164]メリア、T.、エド、 "モビリティサービス交通：問題文"。、RFC 5164、2008年3月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382]グハ、S.、エド。、ビスワス、K.、フォード、B.、シバクマー、S.、およびP. Srisuresh、 "TCPのためのNATの行動の要件"、BCP 142、RFC 5382、2008年10月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]エッゲルト、L.とG. Fairhurst、 "アプリケーションデザイナーのためのユニキャストUDPの使用上の注意事項"、BCP 145、RFC 5405、2008年11月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681]オールマン、M.、パクソン、V.、およびE.ブラントン、 "TCP輻輳制御"、RFC 5681、2009年9月。
Authors' Addresses
著者のアドレス
Telemaco Melia (editor) Alcatel-Lucent Route de Villejust Nozay 91620 France
Telemacoメリア（編集者）アルカテル・ルーセントルートNozay 91620ヴィルジュフランス
EMail: telemaco.melia@alcatel-lucent.com
メールアドレス：telemaco.melia@alcatel-lucent.com
Gabor Bajko Nokia
ガボールノキアBajko
EMail: Gabor.Bajko@nokia.com
メールアドレス：Gabor.Bajko@nokia.com
Subir Das Telcordia Technologies Inc.
Telcordia Technologies Inc.のアップ
EMail: subir@research.telcordia.com
メールアドレス：subir@research.telcordia.com
Nada Golmie NIST
灘Golmie NIST
EMail: nada.golmie@nist.gov
メールアドレス：nada.golmie@nist.gov
Juan Carlos Zuniga InterDigital Communications, LLC
フアン・カルロス・スニガインターデジタルコミュニケーションズ、LLC
EMail: j.c.zuniga@ieee.org
メールアドレス：j.c.zuniga@ieee.org