[要約] RFC 6089は、Mobile IPv6およびNetwork Mobility（NEMO）Basic Supportにおけるフローバインディングに関する規格です。このRFCの目的は、モバイルノードやネットワークモビリティのサポートにおいて、フローバインディングの仕組みを提供することです。
Internet Engineering Task Force (IETF) G. Tsirtsis
Request for Comments: 6089 Qualcomm
Updates: 5648 H. Soliman
Category: Standards Track Elevate Technologies
ISSN: 2070-1721 N. Montavont
IT/TB
G. Giaretta
Qualcomm
K. Kuladinithi
University of Bremen
January 2011
Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support
モバイルIPv6およびネットワークモビリティ（NEMO）のフローバインディング基本サポート
Abstract
概要
This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses.
このドキュメントでは、モバイルIPv6に拡張機能を紹介し、ノードが1つ以上のフローをケアオブアドレスにバインドできるようにします。これらの拡張機能により、マルチホームノードは、ホームエージェントや他のモバイルIPv6エンティティに特定のアドレスにインバウンドフローを向けるよう指示することができます。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc6089.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6089で取得できます。
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ライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 5
4.1. Definition Update for Binding Identifier Mobility
Option . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Flow Identification Mobility Option . . . . . . . . . . . 5
4.2.1. Flow Identification Sub-Options Definition . . . . . . 7
4.2.2. Flow Summary Mobility Option . . . . . . . . . . . . . 11
4.3. Flow Bindings Entries List and Its Relationship to
Binding Cache . . . . . . . . . . . . . . . . . . . . . . 12
5. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 14
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Preferred Care-of Address . . . . . . . . . . . . . . 15
5.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 15
5.2.1. Sending BU with BID Options . . . . . . . . . . . . . 15
5.2.2. Sending BU with Flow Identification Mobility
Options . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.3. Sending BU with a Flow Summary Option . . . . . . . . 17
5.2.4. Removing Flow Bindings . . . . . . . . . . . . . . . . 18
5.2.5. Returning Home . . . . . . . . . . . . . . . . . . . . 18
5.2.6. Receiving Binding Acknowledgements . . . . . . . . . . 19
5.2.7. Return Routability Procedure . . . . . . . . . . . . . 19
5.3. HA, MAP, and CN Considerations . . . . . . . . . . . . . . 19
5.3.1. Handling Binding Identifier Mobility Options . . . . . 20
5.3.2. Handling Flow Identification Mobility Options . . . . 20
5.3.3. Handling Flow Summary Mobility Option . . . . . . . . 23
5.3.4. Flow Binding Removals . . . . . . . . . . . . . . . . 23
5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 24
5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 24
6. MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 25
7. Security considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . . 29
Mobile IPv6 [RFC3775], Dual-Stack MIPv6 (DSMIPv6) [RFC5555], and Network Mobility (NEMO) Basic Support [RFC3963] allow a mobile node / mobile router to manage its mobility using the binding update message, which binds one care-of address to one home address and associated mobile networks. The binding update message can be sent to the home agent. In Mobile IPv6, the binding update can also be sent to a correspondent node or to a mobility anchor point (see [RFC5380]). The semantics of the binding update are limited to care-of address changes. That is, [RFC3775], [RFC5555], and [RFC3963] do not allow a mobile node / mobile router to bind more than one address to the home address. In [RFC5648], Mobile IPv6 and NEMO Basic Support are extended to allow the binding of more than one care-of address to a home address. This specification further extends Mobile IPv6, DSMIPv6, and NEMO Basic Support to allow them to specify policies associated with each binding. A policy can contain a request for special treatment of a particular IPv4 or IPv6 flow, which is viewed as a group of packets matching a traffic selector. Hence, this specification allows a mobile node / mobile router to bind a particular flow to a care-of address without affecting other flows using the same home address. In addition, this specification allows to bind a particular flow to a particular care-of address directly with correspondent node and mobility agents (i.e., home agents [RFC3775] and mobility anchor points [RFC5380]).
モバイルIPv6 [RFC3775]、デュアルスタックMIPV6（DSMIPV6）[RFC5555]、およびネットワークモビリティ（NEMO）の基本サポート[RFC3963]により、バインディングアップデートメッセージを使用してモバイルノード /モバイルルーターがモビリティを管理できます。1つの自宅住所と関連するモバイルネットワークへの住所の。バインディングアップデートメッセージは、ホームエージェントに送信できます。モバイルIPv6では、バインディングアップデートを特派員ノードまたはモビリティアンカーポイントに送信することもできます（[RFC5380]を参照）。バインディングアップデートのセマンティクスは、住所のケアの変更に限定されています。つまり、[RFC3775]、[RFC5555]、および[RFC3963]は、モバイルノード /モバイルルーターが複数の住所を自宅の住所にバインドすることを許可しません。[RFC5648]では、モバイルIPv6とNEMOの基本的なサポートが拡張され、複数の住所を自宅の住所に結合できるようにします。この仕様により、モバイルIPv6、DSMIPV6、およびNEMOの基本サポートがさらに拡張され、各バインディングに関連するポリシーを指定できるようになります。ポリシーには、トラフィックセレクターに一致するパケットのグループと見なされる特定のIPv4またはIPv6フローの特別な処理のリクエストを含めることができます。したがって、この仕様により、モバイルノード /モバイルルーターは、同じホームアドレスを使用して他のフローに影響を与えることなく、特定のフローをケアオブアドレスにバインドできます。さらに、この仕様により、特定のフローを、特派員ノードおよびモビリティエージェント（つまり、ホームエージェント[RFC3775]およびモビリティアンカーポイント[RFC5380]）を使用して、特定のケアオブアドレスに直接結合できます。
In this document, a flow is defined as a set of IP packets matching a traffic selector. A traffic selector can identify the source and destination IP addresses, transport protocol number, the source and destination port numbers and other fields in IP and higher-layer headers. This specification does not define traffic selectors, which are going to be defined in other specifications. This specification, however, does define the traffic selector sub-option format to be used for any specific traffic selector.
このドキュメントでは、フローはトラフィックセレクターに一致するIPパケットのセットとして定義されています。トラフィックセレクターは、IPおよび高層ヘッダーのソースおよび宛先IPアドレス、輸送プロトコル番号、ソースおよび宛先ポート番号、その他のフィールドを識別できます。この仕様は、他の仕様で定義されるトラフィックセレクターを定義するものではありません。ただし、この仕様は、特定のトラフィックセレクターに使用されるトラフィックセレクターサブオプション形式を定義します。
Using the flow identifier option introduced in this specification, a mobile node / mobile router can bind one or more flows to a care-of address while maintaining the reception of other flows on another care-of address. The mobile node / mobile router assembles the flow binding requests based on local policies, link characteristics, and the types of applications running at the time. Such policies are outside the scope of this document.
この仕様で導入されたフロー識別子オプションを使用して、モバイルノード /モバイルルーターは、別のケアのケアで他のフローの受信を維持しながら、1つ以上のフローをアドレスのケアに結合できます。モバイルノード /モバイルルーターは、ローカルポリシー、リンク特性、および当時実行されているアプリケーションの種類に基づいて、フローバインディングリクエストを組み立てます。このようなポリシーは、このドキュメントの範囲外です。
It should be noted that the flow identification mobility option can be associated with any binding update, whether it is sent to a mobility agent or a correspondent node.
モビリティエージェントまたは特派員ノードに送信されるかどうかにかかわらず、フロー識別モビリティオプションは、任意のバインディングアップデートに関連付けることができることに注意する必要があります。
Note that per-packet load balancing may have negative impacts on TCP congestion avoidance mechanisms as it is desirable to maintain order between packets belonging to the same TCP connection. This behavior is specified in [RFC2702]. Other negative impacts are also foreseen for other types of real-time connections due to the potential variations in round-trip time between packets. Moreover, per-packet load-balancing will negatively affect traffic with anti-replay protection mechanisms. Hence, per-packet load balancing is not envisioned in this specification.
パケットごとの負荷分散は、同じTCP接続に属するパケット間の順序を維持することが望ましいため、TCP混雑回避メカニズムにマイナスの影響を与える可能性があることに注意してください。この動作は[RFC2702]で指定されています。パケット間の往復時間の潜在的な変動により、他のタイプのリアルタイム接続にも他のマイナスの影響が予測されています。さらに、パケットごとの負荷分散は、レプレイ防止メカニズムを伴うトラフィックに悪影響を及ぼします。したがって、この仕様では、パケットごとの負荷分散は想定されていません。
In the rest of the document, the term "mobile node" is used to designate either a mobile node as defined in [RFC3775] and [RFC5648], or a mobile router as defined in [RFC3963] unless stated otherwise.
ドキュメントの残りの部分では、「モバイルノード」という用語は、[RFC3775]および[RFC5648]で定義されているモバイルノード、または特に明記しない限り[RFC3963]で定義されているモバイルルーターのいずれかを指定するために使用されます。
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]に記載されているように解釈される。
Terms used in this document are defined in [RFC3753] and [RFC4885]. The following terms are also used in this document:
このドキュメントで使用される用語は、[RFC3753]および[RFC4885]で定義されています。このドキュメントでは、次の用語も使用されています。
Flow: A flow is a sequence of packets for which the mobile node (MN) desires special handling either by the home agent (HA), the corresponding node (CN) or the mobility anchor point (MAP).
フロー：フローは、モバイルノード（MN）がホームエージェント（HA）、対応するノード（CN）、またはモビリティアンカーポイント（MAP）によって特別な取り扱いを望む一連のパケットです。
Traffic Selector: One or more parameters that can be matched against fields in the packet's headers for the purpose of classifying a packet. Examples of such parameters include the source and destination IP addresses, transport protocol number, the source and destination port numbers, and other fields in IP and higher-layer headers.
トラフィックセレクター：パケットを分類する目的で、パケットのヘッダーのフィールドと一致できる1つ以上のパラメーター。このようなパラメーターの例には、ソースおよび宛先IPアドレス、トランスポートプロトコル番号、ソースおよび宛先ポート番号、およびIPおよび高層ヘッダーのその他のフィールドが含まれます。
Flow binding: It consists of a traffic selector, and one or more binding identifiers (BIDs). IP packets from one or more flows that match the traffic selector associated with the flow binding are forwarded to the BIDs associated with the same flow binding.
フローバインディング：トラフィックセレクターと1つ以上の結合識別子（入札）で構成されています。フローバインディングに関連付けられたトラフィックセレクターに一致する1つ以上のフローからのIPパケットは、同じフローバインディングに関連付けられた入札に転送されます。
Flow Identifier: A flow identifier uniquely identifies a flow binding associated with a mobile node. It is generated by a mobile node and is cached in the table of flow binding entries maintained by the MN, HA, CN, or MAP.
フロー識別子：フロー識別子は、モバイルノードに関連付けられたフローバインディングを一意に識別します。これはモバイルノードによって生成され、MN、HA、CN、またはMAPによって維持されているフローバインディングエントリの表にキャッシュされます。
This section introduces extensions to Mobile IPv6 that are necessary for supporting the flow binding mechanism described in this document.
このセクションでは、このドキュメントで説明されているフロー結合メカニズムをサポートするために必要なモバイルIPv6への拡張を紹介します。
This specification updates the definition of the Binding Identifier Mobility option defined in [RFC5648], as follows:
この仕様は、[RFC5648]で定義されているバインディング識別子モビリティオプションの定義を次のように更新します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 35 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding ID (BID) | Status |H| BID-PRI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ +
: IPv4 or IPv6 Care-of Address (CoA) :
+ +
+---------------------------------------------------------------+
Figure 1: The Binding Identifier Mobility Option
図1：バインディング識別子モビリティオプション
BID-PRI
BID-PRI
This is a 7-bit unsigned integer placing each BID to a relative priority (PRI) with other registered BIDs. Value '0' is reserved and MUST NOT be used. A lower number in this field indicates a higher priority, while BIDs with the same BID-PRI value have equal priority meaning that, the BID used is an implementation issue. This is consistent with current practice in packet classifiers.
これは、各入札を他の登録入札と相対的な優先度（PRI）に配置する7ビットの署名のない整数です。値「0」は予約されており、使用してはなりません。このフィールドの数が少ないことは優先度が高いことを示しますが、同じBID-PRI値を持つ入札には同等の優先度があり、使用される入札は実装の問題です。これは、パケット分類子の現在の練習と一致しています。
The flow identification mobility option is a new mobility option [RFC3775], and it is included in the binding update and acknowledgement messages. This option contains information that allows the receiver of a binding update to install policies on a traffic flow and route it to a given care-of address. Multiple options may exist within the same binding update message. The alignment requirement for this option is 2n.
フロー識別モビリティオプションは、新しいモビリティオプション[RFC3775]であり、バインディングアップデートおよび確認メッセージに含まれています。このオプションには、バインディングアップデートの受信者がトラフィックフローにポリシーをインストールし、特定のケアオブアドレスにルーティングできる情報が含まれています。同じバインディングアップデートメッセージ内に複数のオプションが存在する場合があります。このオプションのアライメント要件は2nです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Len | FID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FID-PRI | Reserved | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-options (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Flow Identification Mobility Option
図2：フロー識別モビリティオプション
Option Type
オプションタイプ
45
45
Option Len
オプションレン
Length of the option in octets as per [RFC3775].
[RFC3775]に従って、オクテットのオプションの長さ。
FID
fid
The Flow Identifier field is a 16-bit unsigned integer that includes the unique identifier for the flow binding. This field is used to refer to an existing flow binding or to create a new flow binding. The value of this field is set by the mobile node. FID = 0 is reserved and MUST NOT be used.
フロー識別子フィールドは、フロー結合の一意の識別子を含む16ビットの符号なし整数です。このフィールドは、既存のフロー結合を参照するか、新しいフローバインディングを作成するために使用されます。このフィールドの値は、モバイルノードによって設定されます。FID = 0は予約されており、使用してはなりません。
FID-PRI
fid-pri
This is a 16-bit unsigned integer priority field to indicate the priority of a particular option. This field is needed in cases where two different flow descriptions in two different options overlap. The priority field decides which policy should be executed in those cases. A lower number in this field indicates a higher priority. Value '0' is reserved and MUST NOT be used. FID-PRI MUST be unique to each of the flows pertaining to a given MN. In other words, two FIDs MUST NOT be associated with the same FID-PRI value.
これは、特定のオプションの優先度を示す16ビットの署名のない整数優先度フィールドです。このフィールドは、2つの異なるオプションの2つの異なるフロー記述が重複する場合に必要です。優先フィールドは、そのような場合にどのポリシーを実行すべきかを決定します。このフィールドの数が少ないことは、優先度が高いことを示しています。値「0」は予約されており、使用してはなりません。FID-PRIは、特定のMNに関連する各フローに固有のものでなければなりません。言い換えれば、2つのFIDを同じFID-PRI値に関連付けてはなりません。
Status
スターテス
This 8-bit unsigned integer field indicates the success or failure of the flow binding operation for the particular flow in the option. This field is not relevant to the binding update message as a whole or to other flow identification options. This field is only relevant when included in the Binding Acknowledgement message and must be ignored in the binding update message. The following values are reserved for the Status field within the flow identification mobility option:
この8ビットの署名されていない整数フィールドは、オプションの特定のフローのフロー結合操作の成功または失敗を示します。このフィールドは、バインディングアップデートメッセージ全体または他のフロー識別オプションには関係ありません。このフィールドは、拘束力のある確認メッセージに含まれている場合にのみ関連し、バインディングアップデートメッセージで無視する必要があります。次の値は、フロー識別モビリティオプション内のステータスフィールドに予約されています。
0 Flow binding successful
0フローバインディングが成功しました
128 Administratively prohibited
128管理上禁止
129 Flow binding rejected, reason unspecified
129フローバインディングが拒否された、理由が不特定
130 Flow identification mobility option malformed
130フロー識別モビリティオプション不正さ
131 BID not found
131入札が見つかりません
132 FID not found
132フィッドが見つかりません
133 Traffic selector format not supported
133トラフィックセレクター形式はサポートされていません
Sub-options (optional)
サブオプション（オプション）
Zero or more sub-options, defined in Section 4.2.1.
セクション4.2.1で定義されているゼロ以上のサブオプション。
Flow identification sub-options are encoded within the remaining space of the flow identification mobility option, using a sub-option type-length-value (TLV) format as follows:
フロー識別サブオプションは、次のように、サブオプションタイプ長値（TLV）形式を使用して、フロー識別モビリティオプションの残りのスペース内でエンコードされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Opt Type |Sub-Opt Length | Sub-Option Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flow Identification Sub-Option Format
図3：フロー識別サブオプション形式
Sub-Opt Type
サブOPTタイプ
8-bit unsigned integer indicating the sub-option Type. When processing a flow identification mobility option containing an option for which the sub-option Type value is not recognized by the receiver, the receiver MUST silently ignore and skip over the sub-option, correctly handling any remaining sub-options in the same option.
サブオプションタイプを示す8ビットの符号なし整数。サブオプションタイプの値が受信機によって認識されないオプションを含むフロー識別モビリティオプションを処理する場合、受信者はサブオプションを静かに無視してスキップし、同じオプションで残りのサブオプションを正しく処理する必要があります。
Sub-Opt Len
サブOPTレン
8-bit unsigned integer, representing the length in octets of the flow identification sub-option. This field indicates the length of the sub-option not including the Sub-Opt Type and Sub-Opt Length fields. Note that Sub-Opt Type '0' (Section 4.2.1.1) is a special case that does not take a Sub-Opt Length field.
フロー識別サブオプションのオクテットの長さを表す8ビットの符号なし整数。このフィールドは、サブOPTタイプとサブOPTの長さフィールドを含まないサブオプションの長さを示します。サブOPTタイプ '0'（セクション4.2.1.1）は、サブOPTの長さフィールドを取得しない特別なケースであることに注意してください。
Sub-Option Data
サブオプションデータ
A variable length field that contains data specific to the sub-option.
サブオプションに固有のデータを含む可変長フィールド。
The following subsections specify the sub-option Types that are currently defined for use in the flow identification option. Implementations MUST silently ignore any sub-options that they do not understand.
次のサブセクションでは、フロー識別オプションで使用するために現在定義されているサブオプションタイプを指定します。実装は、彼らが理解していないサブオプションを静かに無視する必要があります。
These sub-options may have alignment requirements. Following the convention in [RFC3775], regarding mobility options, these sub-options are aligned in a packet so that multi-octet values within the sub-option Data field of each sub-option fall on natural boundaries (i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n = 1, 2, 4, or 8).
これらのサブオプションには、アラインメント要件がある場合があります。[RFC3775]の条約に続いて、モビリティオプションに関して、これらのサブオプションはパケットに並べられているため、各サブオプションのサブオプションデータフィールド内のマルチオクテット値が自然境界（すなわち、幅nのフィールドがあります。オクテットは、n = 1、2、4、または8のヘッダーの開始からnオクテットの整数倍に配置されます。
The Pad1 sub-option does not have any alignment requirements. Its format is as follows:
PAD1サブオプションには、アラインメント要件がありません。その形式は次のとおりです。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Sub-Opt Type |
+-+-+-+-+-+-+-+-+
Sub-Opt Type
サブOPTタイプ
0
0
NOTE: The format of the Pad1 sub-option is a special case -- it has neither sub-option Length nor sub-option Data fields.
注：PAD1サブオプションの形式は特別なケースです。サブオプションの長さもサブオプションデータフィールドもありません。
The Pad1 sub-option is used to insert one octet of padding in the flow identification option. If more than one octet of padding is required, the PadN sub-option, described next, should be used rather than multiple Pad1 sub-options.
PAD1サブオプションを使用して、フロー識別オプションに1オクテットのパディングを挿入します。複数のパディングが必要な場合、次に説明したPADNサブオプションを複数のPAD1サブオプションではなく使用する必要があります。
The PadN sub-option does not have any alignment requirements. Its format is as follows:
PADNサブオプションには、アラインメント要件がありません。その形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Sub-Opt Type | Sub-Opt Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Sub-Opt Type
サブOPTタイプ
1
1
Sub-Opt Len
サブOPTレン
Set to the length of the sub-option.
サブオプションの長さに設定します。
Sub-Opt Data
サブOPTデータ
0 or more bytes set to 0 by the sender and ignored by the receiver.
送信者によって0に設定され、受信機によって無視された0以上のバイト。
The PadN sub-option is used to insert two or more octets of padding in the flow identification mobility option. For N octets of padding, the sub-option Length field contains the value N, and the sub-option Data field consists of N-2 zero-valued octets. PadN sub-option Data MUST be ignored by the receiver.
PADNサブオプションは、フロー識別モビリティオプションに2つ以上のパディングを挿入するために使用されます。パディングのnオクテットの場合、サブオプションの長さフィールドには値nが含まれ、サブオプションデータフィールドはn-2ゼロ値のオクテットで構成されます。PADNサブオプションデータは、受信機によって無視する必要があります。
This section introduces the binding reference sub-option, included in the flow identification mobility option. A node MUST NOT include more than one binding reference sub-options in a given flow binding identification option. The binding reference sub-option includes one or more BIDs defined in Multiple Care-of Addresses (MCoA) [RFC5648]. This sub-option associates the flow described in a flow identification mobility option with one or more registered BIDs.
このセクションでは、フロー識別モビリティオプションに含まれるバインディングリファレンスサブオプションを紹介します。ノードには、特定のフローバインディング識別オプションに複数のバインディング参照サブオプションを含めてはなりません。バインディングリファレンスサブオプションには、複数のアドレス（MCOA）[RFC5648]で定義された1つ以上の入札が含まれます。このサブオプションは、フロー識別モビリティオプションに記載されているフローを、1つ以上の登録入札に関連付けます。
When binding a flow using this sub-option, the binding identifier mobility option, defined in [RFC5648], MUST be included in either the same or an earlier binding update (BU). The binding reference sub-option is shown below. The alignment requirement for this sub-option is 2n.
このサブオプションを使用してフローを結合する場合、[RFC5648]で定義されているバインディング識別子モビリティオプションは、同じまたは以前のバインディングアップデート（BU）に含める必要があります。バインディング参照サブオプションを以下に示します。このサブオプションのアライメント要件は2Nです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Opt Type | Sub-Opt Len | BID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BID ........
+-+-+-+-+-+-+-+-+-+-
Figure 4: The Binding Reference Sub-Option
図4：バインディング参照サブオプション
Sub-Opt Type
サブOPTタイプ
2
2
Sub-Opt Len
サブOPTレン
Variable
変数
BID
入札
A 16-bit unsigned integer indicating the BID that the mobile node wants to associate with the flow identification option. One or more BID fields can be included in this sub-option. Since each BID is 2 bytes long, the value of the Sub-opt Len field indicates the number of BIDs present. Number of BIDs = Sub-Opt Len/2.
モバイルノードがフロー識別オプションに関連付けたいという入札を示す16ビットの符号なし整数。このサブオプションには、1つ以上の入札フィールドを含めることができます。各入札は2バイトの長さであるため、サブOPTレンフィールドの値は、存在する入札数を示します。入札数= sub-opt len/2。
The traffic selector sub-option includes the parameters used to match packets for a specific flow binding. A node MUST NOT include more than one traffic selector sub-option in a given flow binding identification option.
トラフィックセレクターサブオプションには、特定のフローバインディングのパケットを一致させるために使用されるパラメーターが含まれます。ノードには、特定のフローバインディング識別オプションに複数のトラフィックセレクターサブオプションを含めてはなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Opt Type | Sub-Opt Len | TS Format | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Selector ...
+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The Traffic Selector Sub-Option
図5：トラフィックセレクターサブオプション
Sub-Opt Type
サブOPTタイプ
3
3
Sub-Opt Len
サブOPTレン
Variable
変数
TS Format
TS形式
An 8-bit unsigned integer indicating the Traffic Selector Format. Value "0" is reserved and MUST NOT be used.
トラフィックセレクター形式を示す8ビットの署名整合体。値「0」は予約されており、使用してはなりません。
Reserved
予約済み
An 8-bit reserved field. It MUST be set to zero by the sender and ignored by the receiver.
8ビット予約フィールド。送信者によってゼロに設定され、受信機によって無視される必要があります。
Traffic Selector
トラフィックセレクター
A variable-length field, the format and content of which is out of scope for this specification. The traffic selector defined in [RFC6088] is mandatory to implement.
この仕様のフォーマットとコンテンツは、形式とコンテンツが範囲外です。[RFC6088]で定義されているトラフィックセレクターは、実装が必須です。
The flow summary mobility option is a new mobility option [RFC3775], which includes one or more flow identifiers (FIDs) for the purpose of refreshing their state. The alignment requirement for this option is 2n.
フローサマリーモビリティオプションは、新しいモビリティオプション[RFC3775]です。これには、状態を更新する目的で1つ以上のフロー識別子（FID）が含まれます。このオプションのアライメント要件は2nです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Len | FID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FID ........
+-+-+-+-+-+-+-+-+-+-
Figure 6: The Flow Summary Mobility Option
図6：フローサマリーモビリティオプション
Option Type
オプションタイプ
44
44
Option Length
オプション長
Length of the option in octets as per [RFC3775].
[RFC3775]に従って、オクテットのオプションの長さ。
FID
fid
A 16-bit unsigned integer indicating a registered FID. One or more FID fields can be included in this option. Number of FIDs = Option Len/2.
登録されたFIDを示す16ビットの署名のない整数。このオプションには、1つ以上のFIDフィールドを含めることができます。fids = option len/2の数。
The conceptual Mobile IPv6 binding cache was defined in [RFC3775] to identify the mobile IP state maintained by the mobile node, mobility agent, and correspondent node. The binding cache includes, among others, the mobile node's home address, the registered care-of address, and the lifetime of the binding. The binding cache has been extended by [RFC5648] to include more than one care-of addresses and to associate each of them with a binding identifier (BID).
概念的なモバイルIPv6バインディングキャッシュは、[RFC3775]で定義され、モバイルノード、モビリティエージェント、および特派員ノードによって維持されるモバイルIP状態を識別しました。バインディングキャッシュには、とりわけ、モバイルノードのホームアドレス、登録されたケアオブアドレス、およびバインディングの寿命が含まれます。結合キャッシュは[RFC5648]によって拡張されており、複数のアドレスを含め、それぞれをバインディング識別子（BID）に関連付けます。
This specification does not modify the Mobile IPv6 binding cache any further.
この仕様では、モバイルIPv6バインディングキャッシュをこれ以上変更しません。
Flow bindings can be thought of as a conceptual list of entries that is separate from the binding cache. The flow bindings list contains an entry for each of the registered flow bindings. Flow binding entries point to an entry in the binding cache by means of the BID. Each flow binding entry includes the following parameters:
フローバインディングは、バインディングキャッシュとは別のエントリの概念リストと考えることができます。Flow Bindingsリストには、登録されたフローバインディングごとにエントリが含まれています。フローバインディングエントリは、入札によるバインディングキャッシュのエントリを指します。各フローバインディングエントリには、次のパラメーターが含まれています。
o FID (Flow Identifier): For a given mobile node, identified by its primary home address, the FID MUST uniquely identify an entry, i.e., a unique flow binding. Each mobile node can only have a single entry identified by a given FID at any one time. A given FID number space is used for all the addresses associated to a given MN by the HA (e.g., via [RFC3963]). Different mobile nodes use the same FID number space.
o FID（Flow Identifier）：主要なホームアドレスによって識別される特定のモバイルノードの場合、FIDはエントリ、つまり一意のフローバインディングを一意に識別する必要があります。各モバイルノードは、一度に特定のFIDによって識別される単一のエントリのみを持つことができます。特定のFID番号スペースは、HAによって特定のMNに関連付けられたすべてのアドレスに使用されます（例：[RFC3963]）。異なるモバイルノードは、同じFID番号スペースを使用します。
o A Traffic Selector: Included in a traffic selector sub-option.
o トラフィックセレクター：トラフィックセレクターサブオプションに含まれています。
o BID(s): The list of BIDs associated with the entry as defined by the binding reference sub-option included in the FID option that created it.
o 入札：それを作成したFIDオプションに含まれるバインディングリファレンスサブオプションによって定義されるエントリに関連付けられた入札のリスト。
o Active/Inactive flag: This flag indicates whether the entry is active or inactive.
o アクティブ/非アクティブフラグ：このフラグは、エントリがアクティブであるか非アクティブかを示します。
o FID-PRI: This field indicates the priority of the flow binding and is used to break the tie between overlapping flow bindings.
o FID-PRI：このフィールドは、フロー結合の優先度を示し、オーバーラップフローバインディング間のネクタイを破るために使用されます。
The flow bindings list is associated with a given mobile node, and the correspondent binding cache. An entry in the flow bindings list, however, is identified by the FID and the list is ordered according to the FID-PRI field as defined in the FID option that created each entry.
Flow Bindingsリストは、特定のモバイルノードと特派員のバインディングキャッシュに関連付けられています。ただし、FIDでFIDで識別され、各エントリを作成したFIDオプションで定義されているFID-PRIフィールドに従ってリストが並べられています。
A valid BID is required to make the entry 'Active'. If all of the BIDs pointed to by a given entry are deregistered [RFC5648], the flow binding entry becomes 'Inactive', in other words it does not affect data traffic. Note that an entry becomes 'Inactive' only if all of the BIDs are deregistered. If only some of the BIDs are still valid, the invalid BIDs are simply ignored.
エントリを「アクティブ」にするには、有効な入札が必要です。特定のエントリによって指摘されたすべての入札が登録された場合[RFC5648]、フロー結合エントリは「非アクティブ」になります。つまり、データトラフィックには影響しません。すべての入札が登録されている場合にのみ、エントリが「非アクティブ」になることに注意してください。一部の入札のみがまだ有効な場合、無効な入札は単に無視されます。
Also, note that the state described in this section is maintained by the mobile node as well as in mobility agents and correspondent nodes. As such, the mobile node is fully aware of which BIDs are valid at any time and which flow binding entries are active/inactive. Section 5 defines how these flow binding entries are manipulated by the mobile node in detail.
また、このセクションで説明する状態は、モバイルノードおよびモビリティエージェントおよび特派員ノードによって維持されていることに注意してください。そのため、モバイルノードは、どの入札がいつでも有効であり、どのフローバインディングエントリがアクティブ/非アクティブであるかを完全に認識しています。セクション5では、これらのフローバインディングエントリがモバイルノードによって詳細に操作される方法を定義しています。
As an example, the following represents an ordered flow binding entry table for a mobile node that has registered multiple care-of addresses and flow bindings.
例として、以下は、複数のアドレスとフローバインディングを登録したモバイルノードの順序付けられたフローバインディングエントリテーブルを表します。
FID-PRI FID Traffic Selector BIDs A/I
------- --- ---------------- ---- -------
10 4 TCP 2 Active
30 2 srcAddr=IPy 4 Inactive
40 5 UDP 1,3 Active
Ordered Flow Binding Entries
順序付けられたフローバインディングエントリ
According to the above list of flow binding entries, all TCP traffic will match the first entry, and will be forwarded to BID2, corresponding to a given care-of address (IP3), as shown below.
上記のフローバインディングエントリのリストによれば、すべてのTCPトラフィックは最初のエントリと一致し、以下に示すように、特定のケアオブアドレス（IP3）に対応するBID2に転送されます。
The second entry is marked as 'Inactive' since the BID 4 does not exist in the ordered list of BID entries below. Inactive entries do not affect traffic, i.e., packets are not matched against them.
2番目のエントリは、以下の入札エントリの順序付けられたリストに存在しないため、「非アクティブ」としてマークされています。非アクティブなエントリはトラフィックに影響しません。つまり、パケットがそれらに対して一致しません。
Any UDP traffic that does not match any of the earlier entries will match the third rule, at which point it will be replicated and forwarded to BIDs 1 and 3, corresponding to care-of addresses IP1 and IP2 shown below.
以前のエントリのいずれかと一致しないUDPトラフィックは、3番目のルールと一致します。その時点で、以下に示すCare of AddressのIP1およびIP2アドレスに対応して、1および3の入札1および3に転送されます。
Finally, any remaining packets that do not match any of the entries above will be simply forwarded to the care-of address indicated by the highest order BID in the table below. In the example, such packets will be forwarded to BID1 corresponding to care-of address IP1.
最後に、上記のエントリのいずれかと一致しない残りのパケットは、以下の表の最高の注文入札で示されるアドレスのケアに単純に転送されます。この例では、そのようなパケットは、Care of Address IP1に対応するBID1に転送されます。
BID-PRI BID CoA
--------- --- ---
20 1 IP1
30 3 IP2
30 2 IP3
Ordered BID Entries
注文入札エントリ
Mobility agent and corresponding node implementations should take care to avoid flow binding rules affecting the fundamental operation of Mobile IPv6 and its extensions. In particular, flow binding rules MUST NOT apply to Mobile IPv6 signaling generated by mobility agents and corresponding nodes communicating with a given mobile node, since that could adversely affect the operation of the protocol. Other, non-MIPv6 traffic generated by these entities SHOULD be matched against the mobile node's flow binding rules as normal.
モビリティエージェントと対応するノードの実装は、モバイルIPv6とその拡張の基本的な動作に影響を与えるフローバインドルールを避けるように注意する必要があります。特に、モビリティエージェントによって生成されたモバイルIPv6シグナル伝達および特定のモバイルノードと通信する対応するノードには、プロトコルの動作に悪影響を与える可能性があるため、フローバインディングルールは適用しないでください。これらのエンティティによって生成されたその他の非MIPV6トラフィックは、通常どおりモバイルノードのフローバインディングルールと一致する必要があります。
This specification introduces a flow bindings list of entries and an ordered list of flow binding identifiers, allowing mobile nodes to associate flow binding policies with the registered care-of addresses.
この仕様では、エントリのフローバインディングリストとフローバインディング識別子の順序付けられたリストを紹介し、モバイルノードが登録されたケアのアドレスと関連するフローバインディングポリシーを関連付けることができます。
The flow identification mobility option defines how the mobile node can control a set of flow binding entries maintained in a mobility agent, or correspondent node.
フロー識別モビリティオプションは、モバイルノードがモビリティエージェントまたは特派員ノードで維持されるフローバインディングエントリのセットを制御する方法を定義します。
This specification allows mobile nodes to direct flows to a particular care-of address. The granularity of what constitutes a flow depends on the traffic selector used.
この仕様により、モバイルノードはフローを特定のアドレスに向けることができます。フローを構成するものの粒度は、使用されるトラフィックセレクターに依存します。
The remainder of this section discusses how mobile nodes can use the options and sub-options defined in this document when sending binding updates to the correspondent node, home agent, or mobility anchor point. In addition, refresh, deletion, and modification of flow binding entries are all discussed below.
このセクションの残りの部分では、特派員ノード、ホームエージェント、またはモビリティアンカーポイントにバインディングアップデートを送信する際に、このドキュメントで定義されているオプションとサブオプションをモバイルノードと使用する方法について説明します。さらに、フローバインディングエントリの更新、削除、および変更については、すべて以下で説明します。
Any node that supports this specification MUST maintain an ordered list of care-of addresses for each mobile node for which it maintains a list of flow bindings. The ordered list of care-of addresses is built based on the BID-PRI field of the binding identifier mobility option (see Section 4.1).
この仕様をサポートするノードは、フローバインディングのリストを維持する各モバイルノードの順序付けられたアドレスのリストを維持する必要があります。順序付けられたアドレスのリストは、バインディング識別子モビリティオプションのBID-PRIフィールドに基づいて構築されています（セクション4.1を参照）。
The ordered list of BIDs is used to determine how to forward a packet to a given mobile node when the packet does not match any of the flow binding entries defined in Section 4.3. A packet that does not match any of the flow binding entries SHOULD be forwarded to the care-of address identified by the BID with the highest priority, i.e., lowest BID-PRI value.
順序付けられた入札リストは、パケットがセクション4.3で定義されているフローバインディングエントリのいずれかと一致しない場合に、特定のモバイルノードにパケットを転送する方法を決定するために使用されます。フローバインディングエントリのいずれかと一致しないパケットは、最優先事項、つまり最低のBID-PRI値を持つ入札で識別される住所に転送する必要があります。
This specification allows the mobile node to maintain several bindings with its mobility agent and correspondent nodes, and it allows it to direct packets to different care-of addresses according to flow bindings.
この仕様により、モバイルノードはモビリティエージェントと特派員ノードを備えたいくつかのバインディングを維持でき、フローバインディングに従ってパケットを異なるアドレスに向けることができます。
The mobility agent and correspondent node list of flow bindings is manipulated by the mobile node, via flow identification and flow summary mobility options included in binding update messages. Each flow binding update can add, modify, refresh, or delete a given binding. More than one flow identification mobility option MAY be included in the same binding update, but each of them MUST include a different FID. In other words, two flow identification options in the same message cannot be about the same flow binding.
フローバインディングのモビリティエージェントと特派員ノードリストは、バインディングアップデートメッセージに含まれるフロー識別とフローサマリーモビリティオプションを介して、モバイルノードによって操作されます。各フローバインディングアップデートは、特定のバインディングを追加、変更、更新、または削除できます。同じバインディングアップデートには、複数のフロー識別モビリティオプションが含まれる場合がありますが、それぞれに異なるFIDを含める必要があります。言い換えれば、同じメッセージの2つのフロー識別オプションは、ほぼ同じフローバインディングではありません。
All flow binding state MUST be refreshed in every binding update the mobile node sends. Any previously registered flow binding that is not included in a given binding update will be deleted. So, any flow bindings that are not added or modified by a flow identification mobility option, but have previously registered and need to be maintained, MUST be included in a flow summary mobility option.
すべてのフローバインド状態は、モバイルノードが送信するすべてのバインディングアップデートで更新する必要があります。特定のバインディングアップデートに含まれていない以前に登録されたフローバインディングは、削除されます。したがって、フロー識別モビリティオプションによって追加または変更されていないが、以前に登録されており、維持する必要があるフローバインディングは、フローサマリーモビリティオプションに含める必要があります。
This specification (see Section 4.1) updates the definition of the binding identifier mobility option, originally defined in [RFC5648]. According to this specification, the BID option includes a BID-PRI field assigning each registered care-of address a priority, and thus places them in an ordered list, as also described in Section 4.3.
この仕様（セクション4.1を参照）は、元々[RFC5648]で定義されたバインディング識別子モビリティオプションの定義を更新します。この仕様によると、BIDオプションには、セクション4.3で説明されているように、登録された各アドレスのケアを優先順位に割り当てるBID-PRIフィールドが含まれているため、順序付けられたリストに配置されています。
To ensure backwards compatibility with [RFC5648], for the purpose of this specification, the field BID-PRI MUST NOT be set to zero.
[RFC5648]との逆方向の互換性を確保するには、この仕様の目的のために、フィールドBID-PRIをゼロに設定してはなりません。
Receiver implementation of this specification will take a BID-PRI field of value zero as an indication that this is a BID option of the format defined in [RFC5648].
この仕様の受信機の実装は、[RFC5648]で定義されている形式のBIDオプションであることを示すものとして、値ゼロのBID-PRIフィールドを取得します。
Mobile nodes supporting this specification MUST use the BID option format defined in Section 4.1. Mobile nodes MUST also register all care-of addresses using the updated BID option format, either in the same BU as any flow identification mobility options using them or in earlier BUs.
この仕様をサポートするモバイルノードは、セクション4.1で定義されているBIDオプション形式を使用する必要があります。また、モバイルノードは、更新されたBIDオプション形式を使用して、すべてのケアオブアドレスを登録する必要があります。
When adding a new flow binding, a mobile node sends the flow identification mobility option in the binding update, with the FID field set to a value that is not already present in the list of flow binding entries maintained by the receiver. The care-of address(es) associated with each flow identification mobility option in the binding update must be logically registered by this binding update, or must have already been registered by the receiver of the binding update in an earlier binding update, as defined in Section 5.2.1.
新しいフローバインディングを追加すると、モバイルノードはバインディングアップデートにフロー識別モビリティオプションを送信します。FIDフィールドは、受信機が維持するフローバインディングエントリのリストにまだ存在しない値に設定されています。バインディングアップデートの各フロー識別モビリティオプションに関連付けられたケアオブアドレスは、このバインディングアップデートによって論理的に登録されている必要があります。セクション5.2.1。
The flow identification mobility option MUST include a unique flow identifier in the FID field. The FID need only be unique for the receiver of the binding update and for the same sender, i.e., the same FID can be used across different receivers of the binding update, for the same sender. The FID-PRI field is set to the desired unique priority of the FID, defining the order of the flow binding to be added in the list of flow binding entries, as defined in Section 4.3. The Status field is set to zero in all binding update messages.
フロー識別モビリティオプションには、FIDフィールドに一意のフロー識別子を含める必要があります。FIDは、バインディングアップデートの受信者と同じ送信者に対してのみ一意である必要があります。つまり、同じ送信者に対して、バインディングアップデートの異なる受信機で同じFIDを使用できます。FID-PRIフィールドは、FIDの目的の一意の優先度に設定されており、セクション4.3で定義されているように、フローバインディングエントリのリストに追加されるフローバインディングの順序を定義します。ステータスフィールドは、すべてのバインディングアップデートメッセージでゼロに設定されています。
Since this flow identification mobility option is requesting the addition of a new flow binding in the list of flow bindings maintained by the receiver, the mobile node MUST include exactly one traffic selector sub-option (see Section 4.2.1.4) describing the flow associated with the new flow binding. The TS Format field of the traffic selector sub-option MUST be set to the non-zero value of the format used by the mobile node.
このフロー識別モビリティオプションは、受信機が維持するフローバインディングのリストに新しいフローバインディングを追加することを要求しているため、モバイルノードには、関連するフローを説明するトラフィックセレクターサブオプション（セクション4.2.1.4を参照）を正確に含める必要があります。新しいフローバインディング。トラフィックセレクターサブオプションのTSフォーマットフィールドは、モバイルノードで使用される形式の非ゼロ値に設定する必要があります。
The mobile node MUST also include exactly one BID reference sub-option (see Section 4.2.1.3) to associate the flow binding with a given set of BIDs and corresponding CoAs.
また、モバイルノードには、フローバインディングを特定の入札セットおよび対応するCOAに関連付けるために、1つの入札参照サブオプション（セクション4.2.1.3を参照）も含める必要があります。
Flow binding modification is essentially a process where parameters associated with an existing flow binding in the list of flow binding entries are replaced by parameters included in the flow identification mobility option, and the same FID is maintained. With this procedure, the mobile node can change the priority, the BID(s), and/or the traffic selector associated with a flow binding.
フロー結合の変更は、基本的に、フローバインディングエントリのリストの既存のフローバインディングに関連付けられたパラメーターが、フロー識別モビリティオプションに含まれるパラメーターに置き換えられ、同じFIDが維持されるプロセスです。この手順により、モバイルノードは、フローバインディングに関連付けられた優先度、入札、および/またはトラフィックセレクターを変更できます。
To modify an existing flow binding, the mobile node MUST send a binding update with a flow identification option, with the FID field set to one of the FID values already in the list of flow binding entries. The FID-PRI field MUST be set to the priority value for the flow binding entry. The Status field is set to zero since this option is in a binding update.
既存のフローバインディングを変更するには、モバイルノードはフロー識別オプションを使用してバインディングアップデートを送信する必要があります。FIDフィールドは、FID値の1つに既にフローバインディングエントリのリストに設定されています。FID-PRIフィールドは、フローバインディングエントリの優先度値に設定する必要があります。このオプションはバインディングアップデートにあるため、ステータスフィールドはゼロに設定されています。
The mobile node MAY include exactly one traffic selector sub-option (see Section 4.2.1.4) describing the updated flow to be associated with the flow binding. The mobile node MAY, however, omit the traffic selector sub-option if it wants the traffic selector currently associated with the flow binding entry identified by the FID field to be maintained.
モバイルノードには、フロー結合に関連する更新されたフローを説明するトラフィックセレクターサブオプション（セクション4.2.1.4を参照）を1つに含めることができます。ただし、モバイルノードは、FIDフィールドによって識別されたフローバインディングエントリに現在関連付けられているトラフィックセレクターが維持される場合、トラフィックセレクターのサブオプションを省略する場合があります。
The mobile node MAY include exactly one binding reference sub-option (see Section 4.2.1.3) to associate the existing flow binding with a new set of CoAs. The mobile node MAY omit the binding reference sub-option if it wants the BIDs currently associated with the flow binding entry identified by the FID field to be maintained.
モバイルノードには、既存のフローバインディングを新しいCOASに関連付けるために、正確に1つのバインディング参照サブオプション（セクション4.2.1.3を参照）を含めることができます。モバイルノードは、FIDフィールドによって識別されたフローバインディングエントリに現在関連付けられている入札が維持される場合、バインディングリファレンスサブオプションを省略する場合があります。
Note that it is also possible for the mobile node to effectively modify the effect of a flow binding entry without actually changing the entry itself. This can be done by changing the CoA associated with a given BID, which is a process defined in detail in [RFC5648].
また、モバイルノードが実際にエントリ自体を変更せずにフローバインドエントリの効果を効果的に変更することも可能であることに注意してください。これは、[RFC5648]で詳細に定義されたプロセスである特定の入札に関連付けられたCOAを変更することで実行できます。
When the mobile node sends a binding update, it MUST refresh all flow bindings it wants to maintain even if it does not want to change any of their parameters.
モバイルノードがバインディングアップデートを送信する場合、パラメーターを変更したくない場合でも、維持したいすべてのフローバインディングを更新する必要があります。
To refresh an existing flow binding, the mobile node MUST send a binding update with a flow summary option. The flow summary option MUST include one or more FID fields, as indicated in Section 4.2.2. Each FID field included MUST be set to one of the FID values already in the list of flow binding entries. Each flow summary mobility option can identify up to 127 FIDs, so more than one such option can be included in a binding update message as required. A given FID SHOULD NOT be included more than once in all of the flow summary mobility options included in a given binding update message.
既存のフローバインディングを更新するには、モバイルノードはフローサマリーオプションを使用してバインディングアップデートを送信する必要があります。セクション4.2.2に示すように、フローの概要オプションには、1つ以上のFIDフィールドを含める必要があります。含まれる各FIDフィールドは、フローバインディングエントリのリストに既にあるFID値の1つに設定する必要があります。各フローサマリーモビリティオプションは最大127のFIDを識別できます。そのため、必要に応じて複数のそのようなオプションをバインディングアップデートメッセージに含めることができます。特定のFIDは、特定のバインディングアップデートメッセージに含まれるすべてのフローサマリーモビリティオプションに複数回含めるべきではありません。
Any flow bindings (active or inactive) that are not identified in a binding update will be removed from the list of flow binding entries.
バインディングアップデートで識別されないフローバインディング（アクティブまたは非アクティブ）は、フローバインディングエントリのリストから削除されます。
Note that any inactive flow bindings, i.e., flow bindings without associated BIDs that are marked as 'Inactive' in the list of flow binding entries (see Section 4.3), MUST also be refreshed, or modified, to be maintained. If they are not included in a BU message, they will be removed.
非アクティブなフローバインディング、つまり、フローバインディングエントリのリスト（セクション4.3を参照）に「非アクティブ」としてマークされた関連入り入札なしのフローバインディングも、維持するために更新または変更する必要があることに注意してください。それらがBUメッセージに含まれていない場合、それらは削除されます。
Removal of flow binding entries is performed implicitly by omission of a given FID from a binding update.
フローバインディングエントリの削除は、バインディングアップデートから特定のFIDを省略することにより暗黙的に実行されます。
To remove a flow binding, the MN simply sends a binding update message that includes flow identification and flow summary mobility options for all the FIDs that need to be refreshed, modified, or added, and simply omits any FIDs that need to be removed.
フローバインディングを削除するために、MNは、更新、変更、または追加する必要があるすべてのFIDのフロー識別とフローサマリーモビリティオプションを含むバインディングアップデートメッセージを送信するだけで、削除する必要があるFIDを省略します。
Note that a mobile node can also render a flow binding inactive by removing the BIDs associated with it, without removing the flow binding itself. The procedure for removing a BID is defined in detail in [RFC5648].
モバイルノードは、フローバインディング自体を削除せずに、それに関連する入札を削除することにより、フロー結合を非アクティブにすることもできます。入札を削除する手順は、[RFC5648]で詳細に定義されています。
When all the BIDs associated with a flow binding are removed, the flow binding MUST be marked as 'Inactive' in the list of flow binding entries, as shown in Section 4.3. In other words, the state associated with the flow binding MUST be maintained, but it no longer affects the mobile node's traffic. The MN can return an inactive flow binding to the active state by using the flow binding modification process, described in Section 5.2.2.2, to associate it again with one or more valid BIDs.
セクション4.3に示すように、フローバインディングに関連付けられたすべての入札が削除された場合、フローバインドエントリのリストのフロー結合は「非アクティブ」としてマークする必要があります。言い換えれば、フロー結合に関連する状態は維持されなければなりませんが、モバイルノードのトラフィックには影響しなくなります。MNは、セクション5.2.2.2で説明されているフロー結合修正プロセスを使用して、1つ以上の有効な入札に再び関連付けることにより、活性状態への非アクティブなフロー結合を返すことができます。
This specification is compatible with the home registration procedures defined in [RFC3775] and [RFC5648]. More specifically, if the mobile node performs a deregistration in the [RFC3775] style, all of its bindings, including flow bindings are deleted. If the mobile node, however, performs a home registration in the [RFC5648] style, then the home link is associated with a specific BID and so, as far as this specification is concerned, it is treated as any other link associated with a given BID.
この仕様は、[RFC3775]および[RFC5648]で定義されている住宅登録手順と互換性があります。より具体的には、モバイルノードが[RFC3775]スタイルで登録を実行する場合、フローバインディングを含むすべてのバインディングが削除されます。ただし、モバイルノードが[RFC5648]スタイルでホーム登録を実行する場合、ホームリンクは特定の入札に関連付けられているため、この仕様に関する限り、特定のリンクに関連する他のリンクとして扱われます。入札。
According to [RFC3775], all nodes are required to silently ignore mobility options not understood while processing binding updates. As such, a mobile node receiving a Binding Acknowledgement message in response to the transmission of a binding update message MUST determine if the Binding Acknowledgement message contains a copy of every flow identification mobility options included in the binding update. A Binding Acknowledgement without flow identification option(s), in response to a binding update with flow identification mobility option, would indicate the inability (or unwillingness) on behalf of the source node to support the extensions presented in this document.
[RFC3775]によると、すべてのノードは、バインディングの更新を処理する際に理解されていないモビリティオプションを静かに無視するために必要です。そのため、バインディングアップデートメッセージの送信に応じてバインディング承認メッセージを受信するモバイルノードは、バインディング確認メッセージに、バインディングアップデートに含まれるすべてのフロー識別モビリティオプションのコピーが含まれているかどうかを判断する必要があります。フロー識別モビリティオプションを使用したバインディングアップデートに応じて、フロー識別オプションのない拘束力のある承認は、ソースノードに代わってこのドキュメントに示されている拡張機能をサポートできないことを示します。
If a received Binding Acknowledgement contains a copy of each flow identification mobility option that was sent within the binding update, the Status field of each flow identification option indicates the status of the flow binding on the distant node.
受信したバインディングの確認に、バインディングアップデート内で送信された各フロー識別モビリティオプションのコピーが含まれている場合、各フロー識別オプションのステータスフィールドは、遠くのノードのフローバインディングのステータスを示します。
A mobile node may perform route optimization with correspondent nodes, as defined in [RFC3775]. Route optimization allows a mobile node to bind a care-of address to a home address in order to allow the correspondent node to direct the traffic to the current location of the mobile node. Before sending a binding update to correspondent node, the Return Routability Procedure needs to be performed between the mobile node and the correspondent node. This procedure is not affected by the extensions defined in this document.
モバイルノードは、[RFC3775]で定義されているように、特派員ノードを使用してルート最適化を実行できます。ルートの最適化により、モバイルノードが住所のケアを自宅の住所にバインドすることを可能にし、特派員ノードがモバイルノードの現在の場所にトラフィックを向けることができます。バインディングアップデートを特派員ノードに送信する前に、モバイルノードと特派員ノードの間で返品ルーティング可能性の手順を実行する必要があります。この手順は、このドキュメントで定義されている拡張機能の影響を受けません。
This specification allows the mobility agents (home agents and mobility anchor points), and correspondent nodes to maintain several flow bindings for a given home address and to direct packets to different care-of addresses according to flow bindings. This section details the home agent operations necessary to implement this specification. These operations are identical for MAPs and CNs, unless otherwise stated.
この仕様により、モビリティエージェント（ホームエージェントとモビリティアンカーポイント）、および特派員ノードが、特定のホームアドレスのいくつかのフローバインディングを維持し、フローバインディングに従ってさまざまなケアアドレスにパケットを向けることができます。このセクションでは、この仕様を実装するために必要なホームエージェント操作について詳しく説明します。これらの操作は、特に明記しない限り、マップとCNSと同じです。
Note that route optimization is only defined for mobile nodes (MIPv6 [RFC3775]) and not mobile routers (NEMOv6 [RFC3963]). Thus, these sections only apply to correspondent nodes with respect to mobile nodes and not mobile routers.
ルート最適化は、モバイルノード（MIPv6 [RFC3775]）に対してのみ定義され、モバイルルーター（Nemov6 [RFC3963]）ではなく定義されていることに注意してください。したがって、これらのセクションは、モバイルルーターではなくモバイルノードに関しての特派員ノードにのみ適用されます。
This specification (see Section 4.1) updates the definition of the binding identifier mobility option, originally defined in [RFC5648]. According to this specification, the BID option includes a BID-PRI field assigning each registered care-of address a priority, and thus places them in an ordered list (see Section 4.3).
この仕様（セクション4.1を参照）は、元々[RFC5648]で定義されたバインディング識別子モビリティオプションの定義を更新します。この仕様によると、BIDオプションには、登録された各住所を優先順位に割り当てるBID-PRIフィールドが含まれているため、順序付けられたリストに配置されます（セクション4.3を参照）。
Home agents receiving BUs including BID options and flow identification options MUST logically process BID options first. This is because BID reference sub-options included in the flow identification mobility options might refer to BIDs defined in BID options included in the same message.
入札オプションやフロー識別オプションを含むバスを受け取るホームエージェントは、最初に入札オプションを論理的に処理する必要があります。これは、フロー識別モビリティオプションに含まれる入札リファレンスサブオプションが、同じメッセージに含まれる入札オプションで定義されている入札を参照する可能性があるためです。
The BID option is processed as defined in [RFC5648], but then the BID to care-of address mapping is placed in an ordered list according to the BID-PRI field of the BID option.
BIDオプションは[RFC5648]で定義されているように処理されますが、アドレスマッピングのケアへの入札は、BIDオプションのBID-PRIフィールドに従って順序付きリストに配置されます。
Binding identifier registrations and deregistrations indirectly affect the MN's flow binding entries. The home agent MUST update the flow binding entries table accordingly as BIDs are added or removed (as per [RFC5648]). For example, as discussed in Section 4.3, if all of the BIDs associated with a given flow binding entry are removed (i.e., become invalid) the entry MUST be marked as 'Inactive'. While if any of the invalid BIDs associated with an inactive flow binding entry are registered (i.e., become valid), the entry MUST be marked as 'Active'.
バインディング識別子登録と規制緩和は、MNのフローバインディングエントリに間接的に影響します。ホームエージェントは、入札が追加または削除されると、フローバインディングエントリテーブルを更新する必要があります（[RFC5648]に従って）。たとえば、セクション4.3で説明したように、特定のフロー結合エントリに関連付けられたすべての入札が削除された場合（つまり、無効になります）、エントリは「非アクティブ」としてマークする必要があります。非アクティブフローバインディングエントリに関連付けられた無効な入札のいずれかが登録されている場合（つまり、有効になる）、エントリは「アクティブ」としてマークする必要があります。
When the home agent receives a binding update that includes at least one flow identification mobility option, it first performs the operation described in section 10.3.1 of RFC 3775, followed by the operations defined in Section 5.3.1 of this document.
ホームエージェントが少なくとも1つのフロー識別モビリティオプションを含むバインディングアップデートを受信すると、最初にRFC 3775のセクション10.3.1で説明されている操作を実行し、その後、このドキュメントのセクション5.3.1で定義された操作が続きます。
Home agents that do not support this specification will ignore the flow identification mobility options and all their sub-options, having no effect on the operation of the rest of the protocol.
この仕様をサポートしていないホームエージェントは、フロー識別モビリティオプションとそのすべてのサブオプションを無視し、残りのプロトコルの動作に影響を与えません。
If the binding update is accepted, and the home agent is willing to support flow bindings for this MN, the home agent checks the flow identification mobility options.
バインディングアップデートが受け入れられ、ホームエージェントがこのMNのフローバインディングをサポートする意思がある場合、ホームエージェントはフロー識別モビリティオプションをチェックします。
If more than one flow identification mobility option in the same BU has the same value in the FID field, all the flow identification mobility options MUST be rejected.
同じBUで複数のフロー識別モビリティオプションがFIDフィールドで同じ値を持っている場合、すべてのフロー識別モビリティオプションを拒否する必要があります。
If all FID fields have different values the flow identification mobility options can be processed further and in any order, as defined by the following subsections.
すべてのFIDフィールドに異なる値がある場合、以下のサブセクションで定義されているように、フロー識別モビリティオプションをさらに処理できます。
If the FID field of the flow identification mobility option is not already present in the list of flow binding entries for this mobile node, then this is a request for a new entry.
フロー識別モビリティオプションのFIDフィールドが、このモバイルノードのフローバインディングエントリのリストにまだ存在していない場合、これは新しいエントリのリクエストです。
If the flow identification mobility option does not include a traffic selector sub-option, the home agent MUST reject this request by copying the flow identification mobility option in the Binding Acknowledgement (BA) and setting the Status field to the value defined in Figure 2 for "Flow identification option malformed".
フロー識別モビリティオプションにトラフィックセレクターのサブオプションが含まれていない場合、ホームエージェントは、バインディング承認（BA）にフロー識別モビリティオプションをコピーし、図2で定義された値にステータスフィールドを設定して、この要求を拒否する必要があります。「フロー識別オプションが奇形」。
If the flow identification option does include a traffic selector sub-option, but the format indicated in the TS Format field is not supported, the home agent MUST reject this request by copying the flow identification mobility option in the BA, and setting the Status field to the value defined in Figure 2 for "Traffic Selector format not supported".
フロー識別オプションにはトラフィックセレクターのサブオプションが含まれているが、TS形式フィールドに示されている形式がサポートされていない場合、ホームエージェントはBAのフロー識別モビリティオプションをコピーし、ステータスフィールドを設定することにより、この要求を拒否する必要があります。「サポートされていないトラフィックセレクター形式」の図2で定義されている値に。
Then, the home agent MUST check the binding reference sub-option.
次に、ホームエージェントはバインディングリファレンスサブオプションを確認する必要があります。
If the binding reference sub-option is not included, the home agent MUST reject this request by copying the flow identification mobility option in the BA and setting the Status field to the value defined for "Flow identification mobility option malformed" in Section 4.2.
バインディング参照サブオプションが含まれていない場合、ホームエージェントは、BAのフロー識別モビリティオプションをコピーし、セクション4.2の「フロー識別モビリティオプションの奇形」の定義された値にステータスフィールドを設定することにより、この要求を拒否する必要があります。
If the binding reference sub-option is present and includes one or more BIDs that are not present in the binding cache of the mobile node, the home agent MUST reject this request by copying the flow identification option in the BA and setting the Status field to the value defined for "BID not found" in Section 4.2.
バインディングリファレンスサブオプションが存在し、モバイルノードのバインディングキャッシュに存在しない1つ以上の入札が含まれている場合、ホームエージェントはBAのフロー識別オプションをコピーしてステータスフィールドを設定することにより、この要求を拒否する必要があります。セクション4.2で「入札不明」で定義された値。
If the binding reference sub-option is present and includes one or more BIDs, and the BIDs exist in the mobile node's binding cache, the home agent SHOULD add a new entry in the mobile node's list of flow binding entries, as defined below.
バインディングリファレンスサブオプションが存在し、1つ以上の入札が含まれ、モバイルノードのバインディングキャッシュに入札が存在する場合、ホームエージェントは、以下に定義するように、モバイルノードのフローバインディングエントリのリストに新しいエントリを追加する必要があります。
When the home agent decides to add an entry in the mobile node's list of flow binding entries, as discussed above, it MUST do it according to the following rules: the entry MUST be placed according to the order indicated by the FID-PRI field of the flow identification mobility option and it MUST include:
上記のように、ホームエージェントがモバイルノードのフローバインディングエントリのリストにエントリを追加することを決定した場合、次のルールに従って行う必要があります。フロー識別モビリティオプションとそれを含める必要があります：
the FID as a key to the entry,
エントリの鍵としてのfid、
the traffic selector included in the corresponding sub-option,
対応するサブオプションに含まれるトラフィックセレクター、
the BIDs indicated in the binding reference sub-option, and
入札は、バインディングリファレンスサブオプションに示されています。
the entry MUST be marked as 'Active', as shown in Section 4.3.
セクション4.3に示すように、エントリは「アクティブ」としてマークする必要があります。
If the FID field of the flow identification mobility option is already present in the list of flow binding entries for this mobile node, then this is a request to update the existing entry.
このモバイルノードのフローバインディングエントリのリストには、フロー識別モビリティモビリティオプションのFIDフィールドがすでに存在している場合、これは既存のエントリを更新するリクエストです。
The flow binding modification is essentially a process where parameters associated with an existing flow binding entry are replaced by the parameters included in a flow identification mobility option with the same FID as the existing entry.
フロー結合の変更は、本質的に、既存のフローバインディングエントリに関連付けられたパラメーターが、既存のエントリと同じFIDを持つフロー識別モビリティオプションに含まれるパラメーターに置き換えるプロセスです。
The home agent MUST change the priority of the entry according to the FID-PRI field of the flow identification mobility option.
ホームエージェントは、フロー識別モビリティオプションのFID-PRIフィールドに従ってエントリの優先度を変更する必要があります。
Since this flow identification mobility option is designed to update an existing entry, it may or may not include a traffic selector sub-option. Specifically:
このフロー識別モビリティオプションは、既存のエントリを更新するように設計されているため、トラフィックセレクターサブオプションが含まれる場合と含まない場合があります。具体的には：
if a traffic selector sub-option is not included in the flow identification mobility option, then the traffic selector already associated with entry MUST be maintained;
トラフィックセレクターのサブオプションがフロー識別モビリティオプションに含まれていない場合、既にエントリに関連付けられているトラフィックセレクターを維持する必要があります。
otherwise, the traffic selector in the entry MUST be replaced by the traffic selector in the sub-option.
それ以外の場合、エントリ内のトラフィックセレクターは、サブオプションのトラフィックセレクターに置き換える必要があります。
Since this flow identification mobility option is designed to update an existing entry, it may or may not include a binding reference sub-option. Specifically:
このフロー識別モビリティオプションは、既存のエントリを更新するように設計されているため、バインディングリファレンスサブオプションが含まれる場合と含まない場合があります。具体的には：
if a binding reference sub-option is not included in the flow identification mobility option, then the BIDs already associated with entry MUST be maintained;
バインディング参照サブオプションがフロー識別モビリティオプションに含まれていない場合、既にエントリに関連付けられている入札を維持する必要があります。
otherwise, the BIDs in the entry MUST be replaced by the BIDs in the sub-option.
それ以外の場合、エントリの入札は、サブオプションの入札に置き換える必要があります。
When the home agent receives a binding update that includes flow summary mobility options, it first performs the operation described so far in Section 5.3.
ホームエージェントがフローサマリーモビリティオプションを含むバインディングアップデートを受信すると、最初にセクション5.3で説明した操作を実行します。
If the value of any of the FID fields included in a flow summary mobility option is not present in the list of flow binding entries for this mobile node, the home agent MUST reject this flow binding refresh by including a flow identification mobility option in the BA for each FID that is not found, and by setting the FID field to the value of the FID that is not found and the Status field to the value defined for "FID not found" in Section 4.2.
フローサマリーモビリティオプションに含まれるFIDフィールドの値が、このモバイルノードのフローバインディングエントリのリストに存在しない場合、ホームエージェントは、BAにフロー識別モビリティオプションを含めることにより、このフローバインディングリフレッシュを拒否する必要があります。見つかっていない各FIDについて、およびFIDフィールドを見つからないFIDの値に設定し、セクション4.2で「FIDが見つかっていない」に対して定義された値にステータスフィールドを設定します。
If the value of the FID field is present in the mobile nodes list of flow binding entries the, home agent SHOULD refresh the flow binding entry identified by the FID without changing any of the other parameters associated with it.
FIDフィールドの値がモバイルノードのフローバインディングエントリのリストに存在する場合、ホームエージェントは、それに関連付けられた他のパラメーターを変更せずにFIDによって識別されるフローバインディングエントリを更新する必要があります。
If a given FID is included more than once in the same or different flow summary mobility options in the same binding update message, the duplicates can be simply ignored.
特定のFIDが同じバインディングアップデートメッセージに同じまたは異なるフローサマリーモビリティオプションに複数回含まれている場合、複製は単に無視できます。
Note that, an [RFC3775] deregistration binding update (with a zero lifetime) would result in deleting all bindings, including all flow bindings regardless of the presence of flow summary mobility options. A binding update (with a zero lifetime) would result in deleting all bindings, including all flow bindings regardless of the presence of flow summary mobility options. A specific binding deregistration, however, as defined in [RFC5648] (with lifetime of zero and one or more binding identifier mobility options identifying specific BIDs) does not remove all the bindings for the MN, and thus it SHOULD include flow summary mobility options to maintain the flow bindings that need to be preserved.
[rfc3775] registrationバインディングアップデート（寿命がゼロで）は、フローサマリーモビリティオプションの存在に関係なく、すべてのフローバインディングを含むすべてのバインディングを削除することに注意してください。バインディングアップデート（寿命がゼロで）は、フローサマリーモビリティオプションの存在に関係なく、すべてのフローバインディングを含むすべてのバインディングを削除します。ただし、[RFC5648]で定義されている特定のバインド式制御（ゼロの寿命と1つ以上の結合識別子モビリティオプションを特定の入札を識別する）では、MNのすべてのバインディングを削除するわけではないため、フローサマリーモビリティオプションを含める必要があります。保存する必要があるフローバインディングを維持します。
Removal of flow bindings is performed implicitly by omission of a given FID from a binding update.
フローバインディングの除去は、バインディングアップデートから特定のFIDを省略することにより暗黙的に実行されます。
When a valid binding update is received, any registered FIDs that are not explicitly referred to in a flow identification mobility option or in a flow summary mobility option, in the same binding update, MUST be removed from the list of flow binding entries for the mobile node.
有効なバインディングアップデートが受信された場合、同じバインディングアップデートで、フロー識別モビリティオプションまたはフローサマリーモビリティオプションで明示的に参照されない登録されたFIDは、モバイルのフローバインディングエントリのリストから削除する必要があります。ノード。
Upon the reception of a binding update, the home agent is required to send back a Binding Acknowledgement. The status code in the Binding Acknowledgement must be set as recommended in [RFC3775]. This status code does not give information on the success or failure of flow bindings.
拘束力のある更新を受信すると、ホームエージェントは拘束力のある謝辞を送り返す必要があります。[RFC3775]で推奨されているように、拘束力のある承認のステータスコードを設定する必要があります。このステータスコードは、フローバインディングの成功または失敗に関する情報を提供しません。
In order to inform the mobile node about the status of the flow binding(s) requested by a mobile node, flow identification options SHOULD be included in the Binding Acknowledgement message. Specifically, the home agent SHOULD copy each flow identification mobility option received in the binding update and set its status code to an appropriate value. Note that the home agent does not need to respond specifically regarding FIDs included in a flow summary mobility option but only to those in flow identification mobility options. If an operation requested in a flow identification option by a mobile node is performed successfully by the home agent, the Status field on the copied flow identification mobility option in the BA, SHOULD be set to the value defined for "Flow binding successful" in Section 4.2; otherwise, it SHOULD be set to one of the rejection codes also defined in Section 4.2. Section 5.3.2 identifies a number of cases where specific error codes should be used.
モバイルノードによって要求されたフローバインディングのステータスについてモバイルノードに通知するには、フロー識別オプションをバインディング確認メッセージに含める必要があります。具体的には、ホームエージェントは、バインディングアップデートで受信した各フロー識別モビリティオプションをコピーし、そのステータスコードを適切な値に設定する必要があります。ホームエージェントは、フローサマリーモビリティオプションに含まれるFIDに関して具体的に応答する必要がないが、フロー識別モビリティオプションのものにのみ対応する必要はないことに注意してください。モバイルノードによってフロー識別オプションで要求された操作がホームエージェントによって正常に実行される場合、BAのコピーされたフロー識別モビリティオプションのステータスフィールドは、セクションで「フローバインド成功」に対して定義された値に設定する必要があります。4.2;それ以外の場合は、セクション4.2で定義されている拒否コードの1つに設定する必要があります。セクション5.3.2では、特定のエラーコードを使用する必要がある多くのケースを識別します。
Home agents that support this specification MAY refuse to maintain flow bindings by setting the Status field of any flow identification mobility options to the value defined for "Administratively prohibited" in Section 4.2, or by just ignoring all the flow binding options.
この仕様をサポートするホームエージェントは、セクション4.2で「管理上禁止」で定義された値にフロー識別モビリティオプションのステータスフィールドを設定するか、すべてのフローバインディングオプションを無視するだけで、フローバインディングを維持することを拒否する場合があります。
Note that BID options and their Status field are handled as defined in [RFC5648]. The BID-PRI field in a BID option included in the Binding Acknowledgement is copied from the BID-PRI field of the corresponding BID option in the binding request.
[RFC5648]で定義されているように、入札オプションとそのステータスフィールドは処理されていることに注意してください。拘束力のある謝辞に含まれるBID-PRIオプションのBID-PRIフィールドは、バインディングリクエストの対応するBIDオプションのBID-PRIフィールドからコピーされます。
This section defines packet processing rules according to this specification. This specification does not change any of the packet interception rules defined in [RFC3775] and [RFC5555]. These rules apply to HAs, MAPs, and CNs as part of the routing process for any packet with a destination address set to a valid home address of the mobile node. For nodes other than CNs, this also applies to packets with a destination address set to an address under any of the registered prefixes. These rules apply equally to IPv6 packets as well as to IPv4 packets as per [RFC5555].
このセクションでは、この仕様に従ってパケット処理ルールを定義します。この仕様では、[RFC3775]および[RFC5555]で定義されているパケットインターセプトルールのいずれも変更しません。これらのルールは、モバイルノードの有効なホームアドレスに設定された宛先アドレスを備えたパケットのルーティングプロセスの一部として、HAS、MAP、およびCNSに適用されます。CNS以外のノードの場合、これは登録されたプレフィックスのいずれかの下にアドレスに設定されている宛先アドレスを持つパケットにも適用されます。これらのルールは、[RFC5555]に従って、IPv6パケットとIPv4パケットに等しく適用されます。
Before a packet is forwarded to the mobile node, it MUST be matched against the ordered list of flow bindings stored in the list of flow binding entries for this mobile node (see Section 4.3). A match is attempted with the traffic selector included in the first line (highest order) of the table. The first entry that creates a match defines how the packet is routed. When a packet matches the traffic selector of a given entry, a copy of the packet is forwarded to each of the care-of addresses associated with the BIDs indicated in the same line of the table.
パケットがモバイルノードに転送される前に、このモバイルノードのフローバインディングエントリのリストに保存されているフローバインディングの順序付けリストと一致する必要があります（セクション4.3を参照）。テーブルの最初の行（最高順序）に含まれるトラフィックセレクターとの一致が試みられます。一致を作成する最初のエントリは、パケットのルーティング方法を定義します。パケットが特定のエントリのトラフィックセレクターと一致する場合、パケットのコピーは、テーブルの同じ行に示されている入札に関連付けられた各アドレスのケアの各アドレスに転送されます。
If any of the BIDs indicated does not correspond to a valid care-of address, e.g., the BID was deregistered then, that BID has no effect on the traffic. In other words, packets matching the flow binding are forwarded to the remaining BIDs, pointing to registered care-of addresses. If none of the BIDs pointed to in a flow binding entry is valid, then the entry is considered to be inactive (as defined in Section 4.3) and is skipped. In other words, packets should not be matched against that entry.
示されている入札のいずれかが有効なケアのケアに対応していない場合、たとえば、その入札が登録された場合、その入札はトラフィックに影響を与えません。言い換えれば、フローバインディングに一致するパケットは、残りの入札に転送され、登録された住所を指し示します。フローバインディングエントリで指摘された入札が有効でない場合、エントリは非アクティブであると見なされ（セクション4.3で定義されています）、スキップされます。つまり、パケットはそのエントリと一致しないでください。
If a packet does not match any of the active flow binding entries for the given MN, the packet SHOULD be forwarded to the highest order care-of address, i.e., the one associated with the BID with the lowest BID-PRI.
パケットが指定されたMNのアクティブフローバインディングエントリのいずれかと一致しない場合、パケットは最高の注文ケアオブアドレス、つまり最低のBID-PRIの入札に関連するものに転送する必要があります。
If a packet is fragmented, only the first fragment contains all IP and transport layer headers, while subsequent fragments only contain an IP header without transport layer headers. For this reason, it is possible that subsequent fragments do not match the same traffic selector as the initial fragment of such a packet. Unless specific measures are taken, the likely outcome is that the initial fragment is routed as the MN intended while subsequent fragments are routed differently, and probably based on the default flow binding. HAs, MAPs, and CNs SHOULD take care to forward all fragments of a given packet the same way, and in accordance to the flow binding matching the first fragment of said packet. This should be possible given the fact that fragment headers include enough information to identify a fragment as part of a specific packet, but the details of how this is ensured are implementation specific and are not defined in this specification.
パケットが断片化されている場合、最初のフラグメントのみにすべてのIPおよびトランスポートレイヤーヘッダーが含まれますが、その後のフラグメントには輸送層ヘッダーのないIPヘッダーのみが含まれます。このため、後続のフラグメントが、そのようなパケットの初期フラグメントと同じトラフィックセレクターと一致しない可能性があります。特定の測定が行われない限り、おそらく結果は、初期フラグメントがMNが意図されているようにルーティングされ、後続のフラグメントは異なる方法でルーティングされ、おそらくデフォルトのフロー結合に基づいていることです。MAPS、およびCNSは、特定のパケットのすべてのフラグメントを同じ方法で転送するように注意する必要があります。フラグメントヘッダーには、特定のパケットの一部としてフラグメントを識別するのに十分な情報が含まれているという事実を考えると、これは可能ですが、これがどのように保証されるかの詳細は実装固有であり、この仕様では定義されていません。
The options and sub-options defined in this specification add to those defined in [RFC3775] and other related specifications, all of which potentially add to the size of binding update messages. Implementations SHOULD take care to minimize fragmentation by forming binding updates that are shorter than what the path MTU allows whenever possible.
この仕様で定義されているオプションとサブオプションは、[RFC3775]およびその他の関連する仕様で定義されているオプションに追加されます。これらはすべて、バインディングアップデートメッセージのサイズに追加されます。実装は、MTUが可能な限り許可するパスよりも短いバインディングアップデートを形成することにより、断片化を最小限に抑えるように注意する必要があります。
This specification offers a number of mechanisms for reducing the size of binding updates. The operations defined in this specification that require the most verbose options are those registering new BIDs, Section 4.1, and identifying new flows, Section 4.2.1.4. Implementations are encouraged to keep binding updates to sizes below that of the path's MTU by making full use of the BID reference sub-option, Section 4.2.1.3, and flow summary option, Section 4.2.2, which allows them to refer to already registered care-of addresses and flow bindings, while registering new ones in subsequent binding update messages.
この仕様は、バインディングアップデートのサイズを削減するための多くのメカニズムを提供します。この仕様で定義されている操作では、最も冗長なオプションが必要な操作は、新しい入札、セクション4.1、および新しいフローの識別、セクション4.2.1.4を識別する操作です。実装は、BIDリファレンスサブオプション、セクション4.2.1.3、およびフローサマリーオプション、セクション4.2.2を最大限に活用することにより、PathのMTU以下のサイズの更新を拘束することをお勧めします。その後のバインディングアップデートメッセージに新しいものを登録しながら、アドレスのケアとフローバインディング。
This document introduces a new option that adds more granularity to the binding update and acknowledgement messages defined in [RFC3775], [RFC5555], and [RFC3963], so it inherits the security considerations discussed in these documents. The new option allows the mobile node to associate some flows to one interface and other flows to another interface. Since the flow identification mobility option is part of the mobility header, it uses the same security as the binding update, whether it is sent to a mobility agent or to a correspondent node.
このドキュメントでは、[RFC3775]、[RFC5555]、および[RFC3963]で定義されているバインディングアップデートと確認メッセージにより多くの粒度を追加する新しいオプションを紹介します。したがって、これらの文書で説明されているセキュリティ上の考慮事項を継承します。新しいオプションにより、モバイルノードは一部のフローを1つのインターフェイスに関連付け、他のフローを別のインターフェイスに関連付けることができます。フロー識別モビリティオプションはモビリティヘッダーの一部であるため、モビリティエージェントであろうと特派員ノードに送信されるかどうかにかかわらず、バインディングアップデートと同じセキュリティを使用します。
This specification does not open up new fundamental lines of attack on communications between the MN and its correspondent nodes. However, it allows attacks of a finer granularity than those on the binding update. For instance, the attacker can divert or replicate flows of special interest to the attacker to an address of the attacker's choosing, if the attacker is able to impersonate the MN or modify a binding update sent by the MN. Hence, it becomes doubly critical that authentication and integrity services are applied to binding updates.
この仕様では、MNとその特派員ノードの間の通信に対する新しい基本的な攻撃ラインを開きません。ただし、バインディングアップデートの攻撃よりも、より細かい粒度の攻撃が可能になります。たとえば、攻撃者がMNになりすましたり、MNから送信されたバインディングアップデートを変更したりできる場合、攻撃者は攻撃者に特別な関心のあるフローを攻撃者に迂回または複製することができます。したがって、認証と整合性のサービスがバインディングの更新に適用されることが二重に重要になります。
Finally, when the optional anti-replay feature of Encapsulating Security Payload (ESP) [RFC4303] is employed and packets to/from different CoAs are sent on the same security association (SA), some packets could be discarded at the receiver due to the windowing mechanism used by this feature. Therefore, a sender SHOULD put traffic to/from different CoAs, but with the same HoA in the selector values, on different SAs to support Multiple Care-of Addresses appropriately. To permit this, the IPsec implementation SHOULD establish and maintain multiple SAs between a given sender and receiver, with the same selectors. Distribution of traffic among these parallel SAs to support Multiple Care-of Addresses is locally determined by the sender and is not negotiated by the Internet Key Exchange version 2 (IKEv2) protocol [RFC5996]. The receiver will process the packets from the different SAs without prejudice.
最後に、セキュリティペイロードをカプセル化するというオプションのアンチレプレイ機能（ESP）[RFC4303]が使用され、異なるCOASのパケットが同じセキュリティ協会（SA）で送信されると、一部のパケットを受信機に捨てることができます。この機能で使用されるウィンドウメカニズム。したがって、送信者は、異なるCOAの間でトラフィックを配置する必要がありますが、セレクター値に同じHOAを使用して、異なるSASで複数のアドレスのケアを適切にサポートする必要があります。これを許可するために、IPSECの実装は、同じセレクターを使用して、特定の送信者と受信機の間で複数のSAを確立および維持する必要があります。これらの並列SAS間のトラフィックの分布は、複数のケアのケアをサポートすることは、送信者によって局所的に決定され、インターネットキーエクスチェンジバージョン2（IKEV2）プロトコル[RFC5996]によって交渉されていません。受信機は、偏見なく異なるSASからパケットを処理します。
This specification requires the following IANA assignments on existing namespaces as well as the creation of some new namespaces.
この仕様では、既存の名前空間での次のIANA割り当てと、いくつかの新しい名前空間の作成が必要です。
New Mobility Options [RFC3775]: This registry is available from http://www.iana.org under "Mobile IPv6 parameters". The following type numbers have been assigned for:
新しいモビリティオプション[RFC3775]：このレジストリは、「モバイルIPv6パラメーター」の下でhttp://www.iana.orgから入手できます。次のタイプ番号が割り当てられています。
44 Flow Identification Mobility Option, defined in Section 4.2
44セクション4.2で定義されているフロー識別モビリティオプションオプション
45 Flow Summary Mobility Option, defined in Section 4.2.2
セクション4.2.2で定義されている45フローサマリーモビリティオプションオプション
A new "Flow Identification Mobility Option Status Codes" namespace has been created. The following 'Status' codes are defined in this specification, in Section 4.2:
新しい「フロー識別モビリティオプションステータスコード」名前空間が作成されました。次の「ステータス」コードは、セクション4.2のこの仕様で定義されています。
0 Flow binding successful
0フローバインディングが成功しました
1-127 Unassigned. Available for success codes to be allocated via Standards Action or IESG Approval as per [RFC5226].
1-127割り当て。[RFC5226]に従って、標準アクションまたはIESGの承認を介して割り当てられる成功コードで利用可能。
128 Administratively prohibited
128管理上禁止
129 Flow binding rejected, reason unspecified
129フローバインディングが拒否された、理由が不特定
130 Flow identification mobility option malformed
130フロー識別モビリティオプション不正さ
131 BID not found
131入札が見つかりません
132 FID not found
132フィッドが見つかりません
133 Traffic selector format not supported
133トラフィックセレクター形式はサポートされていません
134-250 Unassigned. Available for reject codes to be allocated via Standards Action or IESG Approval as per [RFC5226].
134-250が割り当てられていない。[RFC5226]に従って、標準アクションまたはIESGの承認を介して割り当てられるコードを拒否コードに使用できます。
251-255 Reserved for experimental use. This small number of status codes should be sufficient for experiments with currently unforeseen error conditions.
251-255実験用に予約されています。この少数のステータスコードは、現在予期しないエラー条件を使用した実験に十分である必要があります。
A new "Flow Identification Sub-Options" namespace for the flow identification mobility option has been created. The sub-option space is defined in Figure 3. The following sub-option Type values are defined in this specification:
フロー識別モビリティオプションの新しい「フロー識別サブオプション」名前空間が作成されました。サブオプション空間を図3に定義します。次のサブオプションタイプの値をこの仕様で定義しています。
0 Pad
0パッド
1 PadN
1パドン
2 BID Reference
2入札リファレンス
3 Traffic Selector
3トラフィックセレクター
4-250 Unassigned. Available for allocation based on Standards Action or IESG Approval as per [RFC5226].
4-250は割り当てられていません。[RFC5226]に従って、標準訴訟またはIESGの承認に基づいた割り当てに利用できます。
251-255 Reserved for experimental use. This small number of sub-option Types should be sufficient for experiments with additional parameters associated with a flow.
251-255実験用に予約されています。この少数のサブオプションタイプは、フローに関連付けられた追加のパラメーターを使用した実験に十分である必要があります。
A new "Traffic Selector Format" namespace for the traffic selector sub-option has been created. The traffic selector format space is defined by the TS Format field in Figure 5. The following values are defined in this specification:
トラフィックセレクターサブオプションの新しい「トラフィックセレクターフォーマット」名前空間が作成されました。トラフィックセレクター形式のスペースは、図5のTS形式フィールドで定義されます。次の値は、この仕様で定義されています。
0 Reserved
0予約
1-250 Unassigned. Available for allocation based on Standards Action or IESG Approval as per [RFC5226].
1-250は割り当てられていません。[RFC5226]に従って、標準訴訟またはIESGの承認に基づいた割り当てに利用できます。
251-255 Reserved for experimental use. This small number of traffic selector format types should be sufficient for experiments with different ways of representing a traffic selector.
251-255実験用に予約されています。この少数のトラフィックセレクター形式タイプは、トラフィックセレクターを表すさまざまな方法を持つ実験に十分である必要があります。
Similar to the procedures specified for Mobile IPv6 [RFC3775] number spaces, future allocations from the new number spaces requires Standards Action or IESG Approval as per [RFC5226].
モバイルIPv6 [RFC3775]数スペースに指定された手順と同様に、新しい番号スペースからの将来の割り当てには、[RFC5226]に従って標準アクションまたはIESGの承認が必要です。
We would like to explicitly acknowledge the following person who coauthored one of the documents used as source material for this document.
このドキュメントのソース資料として使用されるドキュメントの1つを共著した次の人を明示的に認めたいと思います。
Nikolaus A. Fikouras, niko@comnets.uni-bremen.de
Nikolaus A. Fikouras、niko@comnets.uni-bremen.de
We would also like to acknowledge the following people in alphabetical order for their contributions to this specification: C. Castelluccia, D. Craig, K. ElMalki, K. Georgios, C. Goerg, C. Kaas-Petersen, J. Laganier, T. Noel, V. Park, F.-N. Pavlidou, P. Stupar. Also, Gabor Fekete for the analysis that led to the inclusion of the BID reference sub-option, and Henrik Levkowetz for suggesting support for other ways of describing flows.
また、この仕様への貢献について、以下の人々にアルファベット順に認めたいと思います：C。Castelluccia、D。Craig、K。Elmalki、K。Georgios、C。Goerg、C。Kaas-Petersen、J。Laganier、T T。ノエル、V。パーク、F.-N。Pavlidou、P。Stupar。また、BIDリファレンスサブオプションを含めることにつながった分析のためのGabor Feketeと、フローを説明する他の方法をサポートすることを提案するためのHenrik Levkowetz。
[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月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC3963] Devarapalli、V.、Wakikawa、R.、Petrescu、A。、およびP. Thubert、「ネットワークモビリティ（NEMO）基本的なサポートプロトコル」、RFC 3963、2005年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555] Soliman、H。、「デュアルスタックホストとルーターのモバイルIPv6サポート」、RFC 5555、2009年6月。
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009.
[RFC5648] Wakikawa、R.、Devarapalli、V.、Tsirtsis、G.、Ernst、T。、およびK. Nagami、「複数のケアアドレス登録」、RFC 5648、2009年10月。
[RFC6088] Tsirtsis, G., Giaretta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, January 2011.
[RFC6088] Tsirtsis、G.、Giaretta、G.、Soliman、H。、およびN. Montavont、「フローバインディング用のトラフィックセレクター」、RFC 6088、2011年1月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702] Awduche、D.、Malcolm、J.、Agogbua、J.、O'dell、M。、およびJ. McManus、「MPLS上の交通工学要件」、RFC 2702、1999年9月。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753] MANER、J。およびM. Kojo、「Mobility関連用語」、RFC 3753、2004年6月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[RFC4885] Ernst、T。およびH-Y。Lach、「ネットワークモビリティサポート用語」、RFC 4885、2007年7月。
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[RFC5380] Soliman、H.、Castelluccia、C.、Elmalki、K。、およびL. Bellier、「階層モバイルIPv6（HMIPV6）モビリティ管理」、RFC 5380、2008年10月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「Internet Key Exchange Protocolバージョン2（IKEV2）」、RFC 5996、2010年9月。
Authors' Addresses
著者のアドレス
George Tsirtsis Qualcomm
George Tsirtsis Qualcomm
EMail: tsirtsis@qualcomm.com
Hesham Soliman Elevate Technologies
Hesham Soliman Elevate Technologies
EMail: hesham@elevatemobile.com
Nicolas Montavont Institut Telecom / Telecom Bretagne 2, rue de la chataigneraie Cesson Sevigne 35576 France
ニコラス・モンタヴォント・インスティット・テレコム /テレコム・ブルターニュ2、rue de de la chataigneraie cesson sevigne 35576フランス
Phone: (+33) 2 99 12 70 23
EMail: nicolas.montavont@telecom-bretagne.eu
URI: http://www.rennes.enst-bretagne.fr/~nmontavo//
Gerardo Giaretta Qualcomm
ジェラルド・ジアレッタ・クアルコム
EMail: gerardog@qualcomm.com
Koojana Kuladinithi University of Bremen ComNets-ikom Otto-Hahn-Allee NW 1 Bremen, Bremen 28359 Germany
Koojana Kuladinithi Bremen Comnets-Komom Otto-Hahn-Allee NW 1ブレーメン、ブレーメン28359ドイツ
Phone: +49-421-218-8264
Fax: +49-421-218-3601
EMail: koo@comnets.uni-bremen.de
URI: http://www.comnets.uni-bremen.de/~koo/