Network Working Group M. Liebsch, Ed.
Request for Comments: 4066 A. Singh, Ed.
Category: Experimental H. Chaskar
D. Funato
E. Shim
July 2005
Candidate Access Router Discovery (CARD)
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities and capabilities of candidate ARs (CARs) for handover prior to the initiation of the handover. The act of discovery of CARs has two aspects: identifying the IP addresses of the CARs and finding their capabilities. This process is called "candidate access router discovery" (CARD). At the time of IP-layer handover, the CAR, whose capabilities are a good match to the preferences of the MN, is chosen as the target AR for handover. The protocol described in this document allows a mobile node to perform CARD.
別のアクセスルータ（AR）からモバイルノード（MN）のシームレスなIP層ハンドオーバを有効にするには、MNは、ハンドオーバの開始前にアイデンティティやハンドオーバーのための候補のAR（両）の能力を発見するために必要とされます。自動車のIPアドレスを特定し、その機能を見つける：車の発見の行為は、2つの側面があります。このプロセスは、「候補アクセスルータの発見」（CARD）と呼ばれています。 IP層のハンドオーバー時には、その能力MNの好みに良い一致しているCARは、ハンドオーバのためのターゲットARとして選択されます。本書で説明されたプロトコルは、移動ノードがカードを行うことができます。
Table of Contents
目次
1. Introduction.................................................. 2
2. Terminology................................................... 3
3. CARD Protocol Functions....................................... 4
3.1. Reverse Address Translation............................. 4
3.2. Discovery of CAR Capabilities........................... 4
4. CARD Protocol Operation....................................... 4
4.1. Conceptual Data Structures.............................. 7
4.2. Mobile Node - Access Router Operation................... 8
4.3. Current Access Router - Candidate Access Router
Operation............................................... 11
4.4. CARD Protocol Message Piggybacking on the MN-AR
Interface............................................... 13
5. Protocol Messages............................................. 14
5.1. CARD Messages for the Mobile Node-Access Router
Interface............................................... 14
5.2. CARD Inter-Access Router Messages....................... 28
6. Security Considerations....................................... 31
6.1. Veracity of CARD Information............................ 31
6.2. Security Association between AR and AR.................. 31
6.3. Security Association between AR and MN.................. 32
6.4. Router Certificate Exchange............................. 32
6.5. DoS Attack.............................................. 34
6.6. Replay Attacks.......................................... 34
7. Protocol Constants............................................ 34
8. IANA Considerations........................................... 35
9. Normative References.......................................... 35
10. Informative References........................................ 35
11. Contributors.................................................. 36
12. Acknowledgements.............................................. 36
Appendix A. Maintenance of Address Mapping Tables in
Access Routers....................................... 37
Appendix A.1. Centralized Approach Using a Server Functional
Entity.......................................... 37
Appendix A.2. Decentralized Approach Using Mobile Terminals'
Handover........................................ 38
Appendix B. Application Scenarios................................ 40
Appendix B.1. CARD Operation in a Mobile IPv6-Enabled Wireless
LAN Network..................................... 40
Appendix B.2. CARD Operation in a Fast Mobile IPv6-Enabled
Network......................................... 43
IP mobility protocols, such as Mobile IP, enable mobile nodes to execute IP-level handover among access routers. Work is underway [Kood03][Malk03] to extend the mobility protocols to allow seamless IP handover. Seamless IP mobility protocols will require knowledge of candidate access routers (CARs) to which a mobile node can be transferred. The CAR discovery protocol enables the acquisition of information about the access routers that are candidates for the mobile node's next handover.
そのようなモバイルIPなどのIPモビリティプロトコルは、アクセスルータ間でIPレベルハンドオーバを実行する移動ノードを有効にします。仕事は[Kood03] [Malk03]シームレスなIPハンドオーバを可能にするためのモビリティプロトコルを拡張するために進行中です。シームレスなIPモビリティプロトコルは、移動ノードが転送可能な候補アクセスルータ（両）の知識が必要になります。 CAR発見プロトコルは、モバイルノードの次のハンドオーバのための候補であるアクセスルータに関する情報の取得を可能にします。
CAR discovery involves identifying a CAR's IP address and the capabilities that the mobile node might use for a handover decision. There are cases in which a mobile node has a choice of CARs. The mobile node chooses one according to a match between the mobile node's requirements for a handover candidate and the CAR's capabilities. However, the decision algorithm itself is out of the scope of this document.
CARの発見は、CARのIPアドレスと、移動ノードは、ハンドオーバーの決定のために使用する可能性のある機能を特定する必要。モバイルノードは、自動車の選択肢を持っている場合があります。モバイルノードは、ハンドオーバ候補及びCARの能力のために、移動ノードの要求との間の一致に応じていずれかを選択します。しかし、決定アルゴリズム自体は、この文書の範囲外です。
The problem statement for CAR discovery is documented in [TKCK02]. In this document, a protocol is described to perform CAR discovery. Section 3 describes two main functions of the CAR discovery protocol. Section 4 describes the core part of the CARD protocol operation. The protocol message format is described in Section 5. Section 6 discusses security considerations, and Section 7 contains a table of protocol parameters. Appendix A contains two alternative techniques for dynamically constructing the CAR table mapping between the access point L2 ID and Access Router IP address, which is necessary for reverse address translation. The default method is static configuration. Appendix B contains two sample scenarios for using CARD.
CAR発見のための問題文には、[TKCK02]に記述されています。この文書では、プロトコルは、CARの発見を実行することが記載されています。第3節では、CAR発見プロトコルの2つの主な機能について説明します。セクション4はCARDプロトコル操作のコア部分を記述する。プロトコルメッセージフォーマットはセクション6は、セキュリティ上の考慮事項を説明し、そして部7はプロトコルパラメータのテーブルを含むセクション5に記載されています。付録Aは、動的アクセスポイントL2 IDと逆のアドレス変換に必要なアクセスルータIPアドレスとの間のCARテーブルマッピングを構築するための2つの代替技術を含んでいます。デフォルトの方法は静的な設定です。付録Bには、カードを使用するための2つのサンプルシナリオが含まれています。
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 [Brad97].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [Brad97]に記載されているように解釈されます。
This document uses terminology defined in [MaKo03].
この文書では、[MaKo03]で定義された用語を使用しています。
In addition, the following terms are used:
また、以下の用語が使用されます。
Access Router (AR)
アクセスルータ（AR）
An IP router residing in an access network and connected to one or more APs. An AR offers IP connectivity to MNs.
IPルータは、アクセスネットワーク内に存在し、一台の以上のAPに接続されています。 ARは、MNのへのIP接続を提供しています。
Candidate AR (CAR)
候補AR（CAR）
An AR to which an MN has a choice when performing IP-level handover.
IPレベルでのハンドオーバーを実行するときにARは、MNは選択肢を持っています。
Capability of an AR
ARの機能
A characteristic of the service offered by an AR that may be of interest to an MN when the AR is being considered as a handover candidate.
ARがハンドオーバ候補として検討されているMNに関心のあるARにより提供されるサービスの特性。
L2 ID
ないよう
An identifier of an AP that uniquely identifies that AP. For example, in 802.11, this could be a MAC address of an AP.
一意APことを識別するAPの識別子。例えば、802.11で、これはAPのMACアドレスである可能性があります。
CARD Initiating Trigger
トリガーを開始CARD
An L2 trigger used to initiate the CARD process. For example, a MN can initiate CARD as soon as it detects the L2 ID of a new AP during link layer scan.
L2トリガは、CARDプロセスを開始するために使用されます。例えば、MNは、すぐにそれがリンク層スキャン中に、新たなAPのL2 IDを検出し、カードを開始することができます。
Access Point (AP)
アクセスポイント（AP）
A wireless access point, identified by a MAC address, providing service to the wired network for wireless nodes.
無線ノードのために有線ネットワークにサービスを提供するMACアドレスによって識別された無線アクセスポイント、。
The CARD protocol accomplishes the following functions.
CARDプロトコルは、以下の機能を実現します。
If an MN can listen to the L2 IDs of new APs prior to making a decision about IP-level handover to CARs, a mechanism is needed for reverse address translation. This function of the CARD protocol enables the MN to map the received L2 ID of an AP to the IP address of the associated CAR that connects to the AP. To get the CAR's IP address, the MN sends the L2 ID of the AP to the current AR, and the current AR provides the associated CAR's IP address to the MN.
MNは、車両にIPレベルでのハンドオーバに関する決定を下す前に、新たなAPのL2 IDに聞くことができる場合、メカニズムが逆のアドレス変換のために必要とされています。 CARDプロトコルのこの機能はAPに接続する関連CARのIPアドレスにAPの受信L2 IDをマッピングするためにMNを可能にします。 CARのIPアドレスを取得するには、MNは、現在のARにAPのL2 IDを送信し、現在のARは、MNに関連するCARのIPアドレスを提供します。
Information about the capabilities of CARs can assist the MN in making optimal handover decisions. This capability information serves as input to the target AR selection algorithm. Some of the capability parameters of CARs can be static, whereas others can change with time.
自動車の機能に関する情報は、最適なハンドオーバ決定を行う際にMNを支援することができます。この能力情報は、ターゲットAR選択アルゴリズムへの入力として働きます。他の人が時間とともに変化することができ、一方、自動車の性能パラメータのいくつかは、静的であることができます。
A definition of capabilities is out of the scope of this document. Encoding rules for capabilities and the format of a capability container for capability transport are specified in Section 5.
機能の定義は、この文書の範囲外です。機能及び能力輸送する能力コンテナのフォーマットの符号化規則は、セクション5で規定されています。
The CARD protocol allows MNs to resolve the L2 ID of one or more APs to the IP addresses of the associated CARs. The L2 IDs are typically discovered during an operation by the MN and are potential handover candidates. Additionally, CARD allows MNs to discover particular capabilities associated with the CARs, such as available bandwidth, that might influence the handover decision of the MN. Furthermore, the protocol allows ARs to populate and maintain their local CAR table (Section 4.1) with the capabilities of CARs. For this, the CARD protocol makes use of CARD Request and CARD Reply messages between an MN and its current AR (Section 5.1.2), and between an MN's current AR and individual CARs, respectively (Section 5.2.2).
CARDプロトコルは、MNのは、関連する自動車のIPアドレスへの1つの以上のAPのL2 IDを解決することを可能にします。 L2 IDは、通常、MNによる操作中に発見し、潜在的なハンドオーバ候補でいます。また、カードはMNのハンドオーバの決定に影響を与える可能性があること、のMNは、利用可能な帯域幅などのCARに関連する特定の機能を、発見することができます。さらに、プロトコルは、アクセスルータは、自動車の機能と、ローカルCARテーブル（セクション4.1）を投入し、維持することを可能にします。このために、CARDプロトコルは、CARD要求とカードの使用はMNとその現在のAR（セクション5.1.2）、及びそれぞれMNの現在のARと、個々の車、（5.2.2項）との間でメッセージを返信することができます。
To allow an MN to retrieve a CAR's address and capability information, the CARD Request and CARD Reply messages used between an MN and its current AR may contain one or more access points' L2 IDs and the IP addresses of associated CARs, respectively. Optionally, the CARD Reply messages can also contain a CAR's capability information. A CAR's capabilities are specified as a list of attribute-value pairs, which are conveyed in a Capability Container message parameter.
MNは、CARのアドレスと能力情報を取得できるようにするには、MNとその現在のARの間で使用されるCARD要求とCARD返信メッセージは、それぞれ、一つ以上のアクセスポイントのL2 IDと関連付けられている自動車のIPアドレスが含まれていてもよいです。必要に応じて、CARD返信メッセージもCARの能力情報を含むことができます。 CARの能力は能力コンテナメッセージパラメータに搬送された属性と値のペアのリストとして指定されています。
Information about CARs and associated capabilities MAY be used by the MN to perform target access router selection during its IP handover. The current AR returns replies according to its CAR table (see Section 4.1) and returns a RESOLVER ERROR (see Section 5.1.3.1) if the request cannot be resolved.
車や関連する機能に関する情報は、そのIPハンドオーバ中にターゲットアクセスルータの選択を行うためにMNによって使用されるかもしれません。現在のARは、CARテーブルに従って応答を返す（セクション4.1を参照）、要求は解決できない場合レゾルバERROR（セクション5.1.3.1を参照）を返します。
The CARD protocol also enables an MN to optionally indicate its preferences on capabilities of interest to its current AR by including the Preferences message parameter in the CARD Request message. The MN's current AR MAY use this information to perform optional capability pre-filtering for optimization purposes, and it returns only these capabilities of interest to the requesting MN. The format of this optional Preferences message parameter is described in Section 5.1.3.2.
CARDプロトコルはまたCARD Requestメッセージでの環境設定メッセージパラメータを含めることで、現在のARへの関心の機能への選好を示す任意にMNを可能にします。 MNの現在のARは、最適化のために、オプションの能力プレフィルタリングを実行するためにこの情報を使用することができ、それが要求してMNへの関心の唯一のこれらの機能を返します。このオプションの設定メッセージパラメータのフォーマットは、セクション5.1.3.2に記載されています。
Optionally, the MN can provide its current AR with a list of capability attribute-value pairs, indicating not only the capability parameters (attributes) required for capability pre-filtering, but also a specific value for a particular capability. This allows the MN's current AR to perform CAR pre-filtering and to send only address and capability information of CARs whose capability values meet the requirements of the MN back to the requesting MN. The format of this optional Requirements message parameter is described in Section 5.1.3.3.
必要に応じて、MNは、能力プレフィルタリングするために必要な能力パラメータ（属性）だけでなく、特定の機能のための特定の値だけでなくを示す能力属性値のペアのリストとその現在のARを提供することができます。これは、MNの現在のARはCARプレフィルタリングを実行すると能力値が要求元MNにMNの要件を満たす自動車のアドレスのみと能力情報を送信することができます。このオプションの要件メッセージパラメータのフォーマットは、セクション5.1.3.3に記載されています。
For example, using the optional Preferences message parameter, an MN may indicate to its current AR that it is interested only in IEEE802.11a interface-specific capability parameters, as this is the only interface the MN has implemented. The MN's current AR sends back only CARs with IEEE802.11a-specific capabilities. Similarly, using the optional Requirements message parameter, an MN may indicate to its current AR that it is only interested in CARs that can satisfy a given QoS constraint. Here, an MN sends the respective QoS attribute with the QoS constraint value to its current AR using the optional Requirements message parameter. The QoS constraint is denoted as an attribute-value pair and encapsulated with the
これは、MNが実装している唯一のインターフェースであるように、例えば、オプションのプリファレンスメッセージパラメータを使用して、MNは、それが唯一のIEEE802.11aインターフェース固有の能力パラメータに興味があり、その現在のARに示すことができます。 MNの現在のARは、IEEE802.11aの固有の機能を有する唯一の車を送り返します。同様に、オプションの要件メッセージパラメータを使用して、MNは、所与のQoS制約を満たすことができる車にのみ関心がある、現在のARに示すことができます。ここでは、MNは、それぞれのQoSは、オプションの要件メッセージパラメータを使用して、現在のARにQoS制約値と属性を送信します。 QoSの制約は、属性と値のペアとして示され、でカプセル化されました
Requirements message parameter, which is appended to the MN-originated CARD Request message. The Requirements message parameter may be used to indicate the cutoff values of the capabilities for any desired CARs. According to the received optional list of attributes in the Preferences parameter or a list of attribute-value pairs in the Requirements message parameter, the MN's current AR MAY use these parameters for deciding the content of the solicited CARD Reply message, which is to be sent back to the MN. Alternatively, if the MN's current AR does not perform optimization with regard to capability or CAR pre-filtering, the current AR MAY choose to silently ignore the optional Requirements and Preferences message parameter as received in the CARD Request message.
要件MN由来CARD Requestメッセージに添付されるメッセージパラメータ、。要求メッセージのパラメータは、任意の所望の車のための機能のカットオフ値を示すために使用されてもよいです。環境設定パラメータや要件のメッセージパラメータの属性と値のペアのリスト内の属性の受信オプションのリストによると、MNの現在のARが送信される勧誘CARD Replyメッセージの内容を決定するためにこれらのパラメータを使用してもよい（MAY）バックMNへ。 MNの現在のARが能力やCARプレフィルタリングに関して最適化を実行しない場合は別の方法として、現在のARはCARD Requestメッセージで受信した静かにオプションの要件と環境設定メッセージパラメータを無視することを選ぶかもしれません。
The MN can additionally request from the AR a certification path that is anchored at a certificate from a shared, trusted anchor. The MN includes in the CARD Request message a list of trusted anchors for which the MN has a certificate, and the AR replies with the certification path. If no match is found, the AR returns the trusted anchor names from the CARD Request. The MN can ask for a chain for either the current AR or a CAR. If the trusted anchor list is accompanied by an AP L2 ID for the MN's current AP, the returned chain is for the current AR. If the L2 ID is for an AP that the MN has heard during scanning and is not connected to the current AR, the returned chain is for a CAR. The chain is returned as a sequence of CARD Reply messages, each message containing a single certificate, the L2 identifier for the AP sent in the CARD Request, and a router address for the CAR (or for the AR itself if a request was made for the AR). When the chain is complete, the MN can use it to obtain the AR's certified key and thereby validate signatures on CARD messages and other messages between the MN and the current AR. The MN only has to send the trusted anchor option if it does not have the certification path for the AR already cached. If the MN has the certification path cached, through preconfiguration, through previous receipt of the chain from this router, or by having received the chain through a previous router, then the trusted anchor does not have to be sent. More information about certificate exchange and its use in CARD security can be found in Section 6.
MNは、さらにARから共有、信頼できるアンカーからの証明書に固定された証明書パスを要求することができます。 MNはCARD RequestメッセージにMNが証明書を持っている、信頼できるアンカーのリストが含まれており、ARは、証明書パスで応答します。一致が見つからない場合、ARはCARD要求から信頼されたアンカー名を返します。 MNは、現在のARかCARのいずれかのためにチェーンを求めることができます。信頼されたアンカーリストはMNの現在のAPのためのAP L2 IDを伴っている場合は、返されたチェーンは、現在のARのためです。 L2 IDは、MNは、走査中に聞いており、現在のARに接続されていないことをAPのためのものである場合、返された鎖は、CARのためのものです。要求がために作られた場合、チェーンはCARD応答メッセージの配列、単一の証明書を含む各メッセージ、CARD要求で送信されたAP、およびCARのルータアドレス（またはAR自体のL2識別子として返されますAR）。チェーンが完了すると、MNは、ARの認定キーを取得するためにそれを使用することによりCARDメッセージとMNと現在のARの間に他のメッセージに署名を検証することができます。 MNは、それがすでにキャッシュされたARのための証明書パスを持っていない場合は、信頼できるアンカーオプションを送信する必要があります。 MNは、このルータからチェーンの前の領収書を通じて、または以前のルータを介してチェーンを受けたことにより、事前設定によって、キャッシュされた証明書パスを持っている場合は、信頼できるアンカーが送信されている必要はありません。証明書の交換とカードのセキュリティでの使用の詳細については、第6節で見つけることができます。
The CARD protocol operation, as described in this section, distinguishes signaling messages exchanged between an MN and its current AR from those exchanged between ARs. Hence, descriptions of signaling messages in the following sections have preceding identifiers referring to the associated interface. Messages that are exchanged between an MN and AR are designated as "MN-AR", and messages between ARs are designated as "AR-AR".
CARDプロトコルの動作は、このセクションで説明したように、シグナリングメッセージは、MNとアクセスルータとの間で交換されるものから、現在のARとの間で交換区別する。したがって、以下のセクションのシグナリングメッセージの説明は、関連付けられたインターフェイスを参照識別子を先行しています。 MNとARの間で交換されるメッセージには、「MN-AR」として指定されている、とルータ間のメッセージは、「AR-AR」として指定されています。
+--------------+ (1a)AR-AR CARD Request +----------+
| Current |------------------------->| CAR |
| AR |<-------------------------| |
+--------------+ (2a)AR-AR CARD Reply +----------+
^ |
| | MN-AR
MN-AR | | CARD Reply(3m)
CARD Request(2m) V
+--------------+
| Mobile |
| Node |<-- CARD Init Trigger
+--------------+ (1m)
Figure 1: MN-initiated CARD Protocol Overview
図1：MN-開始CARDプロトコルの概要
Figure 1 describes the operation of the MN-AR CARD Request/Reply protocol and AR-AR CARD Request/Reply protocol. On receipt of the access points' L2 IDs or the appearance of a CARD initiation trigger (1m), the MN may pass on one or more AP L2 IDs to its current AR using the MN-AR CARD Request message (2m). If the MN wants its AR to perform capability discovery in addition to reverse address translation, this must be indicated in the MN-AR CARD Request message by setting the C-flag. If the C-flag is not set, the AR receiving the CARD Request message will perform only reverse address translation. The MN's current AR resolves the L2 ID to the IP address of the associated CAR or, if the MN has not attached any L2 ID message parameters, just reads out all CARs' IP address information using the reverse address translation information (L2 ID to IP address mapping) from its local CAR table. The current AR then returns to the MN using the MN-AR CARD Reply message (3m), the IP addresses of any CARs, each CAR's set of L2 IDs with CANDIDATE indicated in the L2 ID sub-option status field, and, if capability information has been requested, associated capabilities.
図1は、/プロトコル返信/プロトコルおよびAR-AR CARD要求返信MN-ARのCARD要求の動作を説明します。アクセスポイントのL2 IDまたはCARD開始トリガ（1M）の出現を受信すると、MNは、MN-AR CARD要求メッセージ（2M）を用いて、現在のARへの1つまたは複数のAP L2 IDに渡すことができます。 MNは、アドレス変換を逆にするだけでなく、能力発見を実行するためにそのARを望んでいる場合、これはC-フラグを設定することにより、MN-AR CARD Requestメッセージに示されなければなりません。 Cフラグが設定されていない場合、CARD要求メッセージを受信したARは、アドレス変換を逆に実行します。 MNは、任意のL2 IDのメッセージパラメータを添付していない場合はMNの現在のARは、単にIPとは逆のアドレス変換情報（L2 IDを使用して、すべての車のIPアドレス情報を読み出し、関連するCARのIPアドレスへのL2 IDを解決しますかそのローカルCARテーブルからアドレスマッピング）。機能場合、現在のARは、次にMN-ARのCARD Replyメッセージ（3M）を使用してMNに戻り、任意の自動車のIPアドレスが候補とL2 IDの各かごのセットは、L2 IDサブオプションのステータスフィールドに示され、そして情報は、関連する機能が要求されています。
For the AR-AR CARD Request/Reply protocol, the requesting AR sends a CARD Request message to its peer when the CAR table entries time out (1a). The peer returns a CARD Reply message with the requested information (2a).
AR-ARのCARD要求の/プロトコル返信CARテーブルがタイムアウト（1a）をエントリするとき、要求ARがそのピアにCARD要求メッセージを送信します。ピアは、要求された情報（2A）とCARD応答メッセージを返します。
ARs SHALL maintain an L2-L3 address mapping table (CAR table) that is used to resolve L2 IDs of candidate APs to the IP address of the associated CAR. By default, this address-mapping table is configured statically for the CARD protocol operation. Optionally, the CAR table MAY be populated dynamically. Two possible approaches are described in Appendices A.1 and A.2.
ARは、関連CARのIPアドレスに候補APのL2 IDを解決するために使用される（CARテーブル）L2-L3アドレス・マッピング・テーブルを維持しなければなりません。デフォルトでは、このアドレスマッピングテーブルは、CARDプロトコル動作のために静的に設定されています。必要に応じて、CARテーブルが動的に読み込まれるかもしれません。二つの可能なアプローチは、付録A.1とA.2で説明されています。
ARs SHOULD also keep and maintain individual CARs' capabilities in the local CAR table, with the associated capability lifetime taken into account. If the lifetime of an individual capability entry has expired, the respective capability information is updated. An AR may also initiate capability exchange prior to expiration of the capabilities associated with a CAR in the CAR table, thereby populating its CAR table. The AR's CAR table may be implemented differently; therefore additional details are not provided here. ARs MUST maintain their own AP-to-AR mappings and capability information in their CAR tables, in order to provide newly booted MNs with this information so that an MN can obtain the AR's certification path.
ARも考慮に関連する機能の寿命で、地元のCARテーブル内の個々の車の性能を維持し、維持すべきです。個々の能力のエントリのライフタイムの有効期限が切れている場合、それぞれの能力情報が更新されます。 ARは、また、それによって、そのCARテーブルをポピュレートする、前CARテーブルのCARに関連付けられた機能の満了に能力交換を開始することができます。 ARのCARテーブルは異なる方法で実装することができます。したがって、追加の詳細は、ここで提供されていません。 ARは、MNがARの証明書パスを取得できるように、この情報を、新たに起動したMNを提供するために、彼らのCARテーブルに自分のAP-に-ARのマッピングおよび機能情報を維持しなければなりません。
MNs SHOULD maintain discovered address and capability information of CARs in a local cache to avoid requesting the same information repeatedly and to select an appropriate target AR from the list of CARs as quickly as possible when a handover is imminent.
MNが、繰り返し同じ情報を要求回避し、ハンドオーバが迫っているとき、可能な限り迅速に自動車のリストから適切なターゲットARを選択するために、ローカルキャッシュに自動車の発見アドレスと能力情報を維持する必要があります。
To initiate CARD, an MN sends a CARD Request to its current AR, requesting it to resolve the L2 ID of nearby access points to the IP address of associated CARs and also obtain capability parameters associated with these CARs. If the requesting MN wants its current AR to resolve specific L2 IDs, the MN-AR CARD Request MUST contain the CARD protocol-specific L2 ID message parameters. If the MN wants its AR to perform only reverse address translation without appending the CARs' capabilities, the MN refrains from setting the C-flag in the CARD Request message. If the MN wants to perform capability discovery, the MN MUST set the C-flag in the CARD Request message. The CARD Request MAY also contain the Preferences or Requirements message parameter, indicating the MN's preferences on capability attributes of interest or its requirements on CARs' capability attribute-value pairs.
CARDを開始するには、MNは、関連する自動車のIPアドレスに近くのアクセスポイントのL2 IDを解決し、また、これらの車に関連付けられた機能のパラメータを取得することを要求し、その現在のARにCARD要求を送信します。要求MNが現在のARは、特定のL2 IDを解決したい場合は、MN-ARカード要求はCARDプロトコル固有のL2 IDのメッセージパラメータを含まなければなりません。 MNは、そのARは、車の機能を追加することなく、唯一の逆アドレス変換を実行したい場合は、MNがCARD RequestメッセージにCフラグを設定することを控えます。 MNは、能力発見を実行したい場合は、MNがCARD RequestメッセージにCフラグを設定しなければなりません。 CARD要求も、能力、関心の属性や車の能力の属性と値のペアにその要件にMNの好みを示す、環境や要件メッセージパラメータを含むかもしれません。
If the MN appends multiple L2 ID sub-options to a CARD Request, the AR MUST assume that each L2 ID is associated with an AP that connects to a different CAR. Since L2 IDs, address information, and capability information are transmitted with separate sub-options, each sub-option carries a Context-ID, to allow parameters that belong together to be matched. Therefore, the MN MUST assign different Context-ID values to the L2 ID sub-options it appends to the CARD Request message. The Status-Code field of the L2 ID sub-option MUST always be set to NONE (0x00) by the MN. The MN MUST set the sequence number to a randomly generated value, and the AR MUST include the sequence number in all messages of the reply. If the reply spans multiple messages, each message contains the same sequence number.
MNは、CARD要求に複数のL2 IDサブオプションを追加した場合、ARは、各L2 IDが異なるCARに接続するAPに関連付けられていることを前提としなければなりません。 L2 IDを、アドレス情報、および能力情報が別々のサブオプションで送信されるので、各サブオプションが一致するために一緒に属するパラメータを可能にするために、コンテクストIDを運びます。したがって、MNは、CARD要求メッセージに付加L2 IDサブオプションに異なるコンテキスト-ID値を割り当てる必要があります。 L2 IDサブオプションのステータスコードフィールドは常にMNによってNONE（$ 00）に設定しなければなりません。 MNは、ランダムに生成された値にシーケンス番号を設定しなければならない、とARは、応答のすべてのメッセージのシーケンス番号を含まなければなりません。返信が複数のメッセージにまたがる場合、各メッセージは同じシーケンス番号が含まれています。
Upon receipt of the corresponding MN-AR CARD Reply message, the MN correlates the CARD Reply with the appropriate CARD Request message and then processes all MN-AR CARD Reply message parameters to retrieve its CAR's address and capability information. If the MN is unable to correlate the CARD Reply with any previously sent CARD Request messages, the MN SHOULD silently discard the reply. This may happen when the MN reboots after sending a CARD Request message to the connected AR.
対応するMN-AR CARD Replyメッセージを受信すると、MNは、適切なCARD RequestメッセージをCARD Replyを相関させ、そのCARのアドレスと能力情報を取得するために、すべてのMN-AR CARD Replyメッセージのパラメータを処理します。 MNは、以前に送られたCARD要求メッセージをCARD Replyを関連付けることができない場合は、MNは静かに返事を捨てます。 MNが接続されているARにCARD Requestメッセージを送信した後に再起動したときにこれが発生する可能性があります。
An MN uses exponential backoff to retransmit the CARD Request in the event that a CARD Reply is not received within CARD_REQUEST_RETRY seconds. The retransmitted CARD Request MUST have the same sequence number as the original. With the exception of certification paths, which are large by nature, an AR SHOULD attempt to limit the information in a CARD Reply to a single message. Should that be impossible, the AR MAY send the reply in multiple messages. The last message of a reply MUST always have the L-flag set in the CARD Reply option to indicate that the message is the last for the associated sequence number. An AR retransmitting replies to a CARD Request MUST always send the full CARD Reply sequence. The Trusted Anchor sub-option and the Router Certificate sub-option provide a means whereby the MN can request specific certificates in a certification path, in the event that the CARD Reply carrying a certification path spans multiple messages and one of them is lost. However, a request for specific certificates that were not received in the initial CARD Reply MUST be treated as a new request by the MN and MUST use a different sequence number.
MNは、カード返信CARD_REQUEST_RETRY秒以内に受信されない場合に、CARD要求を再送信するために、指数バックオフを使用しています。再送CARD要求は、オリジナルと同じシーケンス番号を持たなければなりません。本質的に大きい証明経路を除いて、ARは、単一のメッセージにCARD応答内の情報を制限しようとすべきです。それは不可能である必要があり、ARは複数のメッセージに返信を送ることができます。応答の最後のメッセージは、常に、メッセージが関連するシーケンス番号の最後であることを示すためにCARD返信オプションで設定Lフラグを持たなければなりません。 CARD要求に応答を再送信するARは常にフルCARD返信シーケンスを送らなければなりません。信頼アンカーサブオプションおよびルータ証明書のサブオプションは、MNは、証明書パスを運ぶCARD返信が複数のメッセージにまたがり、そのうちの一つが失われた場合には、証明書パスに特定の証明書を要求することができる手段を提供します。しかし、初期CARD返信に受信されなかった特定の証明書の要求は、MNによって新しいリクエストとして扱う必要があり、異なるシーケンス番号を使用しなければなりません。
Processing the Context-ID of Address sub-options allows the MN to assign the resolved IP address of a specific CAR to an L2 ID.
アドレスサブオプションの内容-IDを処理すると、MNがL2 IDに固有のCARの解決IPアドレスを割り当てることができます。
In some cases, an L2 ID parameter is present in a CARD Reply message. The Status-Code field in the L2 ID parameter indicates one of the following reasons for its being sent toward the MN.
いくつかのケースでは、L2 IDパラメータは、CARD応答メッセージ内に存在します。 L2 IDパラメータのステータスコードフィールドには、そのは、MNに向かって送信されるため、次のいずれかの理由を示します。
RESOLVER ERROR Status-Code indication: If the MN's current AR could not resolve a particular L2 ID, this status code is returned to the MN.
RESOLVER ERRORステータス・コード表示：MNの現在のARは、特定のL2 IDを解決できませんでした場合は、このステータスコードは、MNに返されます。
MATCH Status-Code indication: If an L2 ID is encountered that shares a CAR with a previously resolved L2 ID, the AR returns MATCH to the MN. This status code indicates that the Context-ID of this particular L2 ID sub-option has been set to the Context-ID of the associated CAR's Address and Capability Container sub-option, which is sent with this CARD Reply message. This approach avoids sending the same CAR's address and capability information multiple times with the same CARD Reply message in case two or more L2 IDs resolve to the same
MATCHのステータスコード表示：L2 IDが以前に解決さL2 IDと共有CARことに遭遇した場合、ARは、MNにMATCHを返します。このステータスコードは、この特定のL2 IDサブオプションのコンテクストIDはこのカード応答メッセージと共に送信される関連CARのアドレスと能力コンテナサブオプションのコンテキストIDに設定されていることを示しています。このアプローチは、2つの以上のL2 IDが同じに解決する場合には、同じCARD Replyメッセージと同じCARのアドレスと能力情報を複数回送信しません
CAR. An MN uses the Context-ID received in the L2 ID sub-option as the key to find the serving CAR of the given AP from the content of the received CARD Reply message.
車。 MNは、コンテキストIDを受信CARD Replyメッセージの内容から与えられたAPのサービング車を見つけるためのキーとしてL2 IDサブオプションで受信使用します。
CANDIDATE Status-Code indication: If the MN does not append any L2 ID to the CARD Request, the AR sends back the L2 ID and address information of all CARs. Because the received parameters' Context-IDs cannot be correlated with an L2 ID's Context-ID of a previously sent request, the AR chooses values for the Context-ID and marks these candidate L2 IDs with CANDIDATE in the status code of the distributed L2 IDs. However, individual values of L2 IDs' Context-ID allow the MN to assign a particular L2 ID to the associated Address and the possibly received Capability Container sub-option.
CANDIDATEのステータスコードの表示は：MNがCARD要求に任意のL2 IDを付加しない場合は、ARは、L2 IDを返信し、すべての車の情報を扱います。受信されたパラメータコンテキストIDが以前に送信された要求のL2 IDのコンテキスト-IDと相関させることができないので、ARは、コンテキストIDの値を選択し、分散L2 IDのステータスコードは、候補とこれらの候補L2 IDをマーク。しかし、L2 IDがコンテクストIDの個々の値は、MNは、関連するアドレスおよびおそらく受信能力コンテナサブオプションに特定のL2 IDを割り当てることができます。
As described in Section 4.5, an MN can use CARD when it initially boots up to determine whether piggyback operation is possible. An MN can also use CARD initially to determine the capabilities and certificates for an AR on which it boots up or if it cannot obtain the certificates beforehand. To do this, the MN includes an L2 Identifier option with its current AP L2 ID and the requested information. The AR replies with its own information.
4.5節で述べたように、それは最初にピギーバック動作が可能であるかどうかを判断するためにブートアップ時に、MNは、カードを使用することができます。 MNはまた、事前に証明書を取得できない場合、それはアップブーツやその上のARのための機能と証明書を決定するために最初にカードを使用することができます。これを行うには、MNは、その現在のAP L2 IDと、要求された情報とL2識別子オプションを含んでいます。 ARは、独自の情報で応答します。
Upon receipt of an MN's MN-AR CARD Request, the connected AR SHALL resolve the requested APs' L2 ID to the IP address of any associated CARs. If no L2 ID parameter has been sent with the MN-AR CARD Request message, the receiving AR retrieves all CARs' IP addresses and, if the C-flag was set in the request, the capability information.
MNのMN-ARカード要求を受信すると、接続されているARは、関連するすべての自動車のIPアドレスに要求されたAPのL2 IDを解決するものとします。何L2 IDパラメータは、MN-ARのCARD Requestメッセージで送信されていない場合、受信側ARは、すべての車のIPアドレスと、C-フラグが要求に設定された場合、能力情報を取得します。
In the first case, where the AR resolves only requested L2 IDs, the AR does not send back the L2 ID to the requesting MN. If, however, two or more L2 IDs match the same CAR information, the L2 ID sub-option is sent back to the MN, indicating a MATCH in the Status-Code field of the L2 ID. Furthermore, the AR sets the Context-ID of the returned L2 ID to the value of the resolved CAR's L2 ID, Address, and Capability Container sub-option. If an AR cannot resolve a particular L2 ID, an L2 ID sub-option is sent back to the MN, indicating a RESOLVER ERROR in the L2 ID sub-option's Status-Code field.
ARのみL2 IDを要求された解決最初のケースでは、ARは、要求元のMNにL2 IDを返送しません。しかし、二つ以上のL2 IDが同じ車情報と一致する場合、L2 IDサブオプションは、L2 IDのステータスコードフィールドに一致を示す、バックMNに送信されます。さらに、ARは解決CARのL2のID、アドレス、および能力コンテナサブオプションの値に戻ったL2 IDのコンテキスト-IDを設定します。 ARは、特定のL2 IDを解決できない場合は、L2 IDサブオプションはL2 IDサブオプションのステータスコードフィールドにリゾルバエラーを示す、バックMNに送信されます。
In the second case, where the AR did not receive any L2 ID with a CARD Request, all candidate APs' L2 IDs are sent to a requesting MN with the CARD Reply message. The AR marks the Status-Code of individual L2 IDs as CANDIDATE, indicating to the MN that the associated Context-ID cannot be matched with the ID of a previously sent request.
ARは、CARD要求に任意のL2 IDを受け取っていない第二の場合には、全ての候補APのL2 IDは、CARD応答メッセージで要求元MNに送信されます。 ARは、関連したコンテキストIDが以前に送信した要求のIDと一致することができないことをMNに知らせる、候補として個々L2 IDのステータスコードをマークします。
In any case, the AR MUST set the Context-ID of the Address and the Capability Container sub-option to the same value as that of the associated L2 ID sub-option.
いずれの場合においても、ARは、コンテキストID関連するL2 IDサブオプションと同じ値へのアドレスと能力コンテナサブオプションを設定しなければなりません。
Optionally, when allowed by local policies and supported by respective ARs for capability discovery, the AR MAY retrieve a subset of capabilities or CARs, satisfying the optionally appended Preferences and Requirement message parameter, from its local CAR table. CARs' address information and associated capabilities are then delivered to the MN using the MN-AR CARD Reply message. The CARs' IP address and the capabilities SHALL be encoded according to the format for CARD protocol message parameters as defined in Section 5.1.3 of this document. The capabilities are encoded as attribute-value pairs, which are encapsulated in a Capability Container message parameter according to the format defined in Section 5.1.3.4. The responding current AR SHALL copy the sequence number received in the MN-AR CARD Request to the MN-AR CARD Reply.
ローカルポリシーによって許可され、能力発見のために各アクセスルータによってサポートされている場合、任意に、ARは、そのローカルCARテーブルから、必要に応じて添付環境と要求メッセージのパラメータを満たす、機能や車のサブセットを取り出すことができます。車のアドレス情報と関連した機能は、MN-AR CARD Replyメッセージを使用してMNに配信されます。このドキュメントのセクション5.1.3で定義されるように車のIPアドレスおよび機能は、CARDプロトコルメッセージパラメータのフォーマットに従って符号化されます。機能は、セクション5.1.3.4で定義されたフォーマットに従って能力コンテナメッセージパラメータでカプセル化された属性値ペアとして符号化されます。応答現在のARは、MN-ARカード返信にMN-ARカード要求で受信したシーケンス番号をコピーするものとします。
The MN's current AR MAY initiate capability exchange with CARs either when it receives an MN-AR CARD Request or when it detects that one or more of its local CAR table's capability entries' lifetimes are about to expire. An AR SHOULD preferentially utilize its CAR table to fulfill requests rather than signal the CAR directly, and it SHOULD keep the CAR table up to date for this purpose, in order to avoid injecting unnecessary delays into the MN response.
それはMN-ARカードの要求またはとき、それはそのローカルCARテーブルの能力のエントリー寿命の1以上の有効期限が近づいていることを検出を受信したときにMNの現在のARは、いずれかのCARと能力交換を開始することができます。 ARは、優先的に要求を満たすのではなく、直接CARに信号を送るためにそのCARテーブルを利用すべきで、それはMN応答に不必要な遅延を注入しないようにするためには、この目的のために最新のCARテーブルを維持する必要があります。
The AR SHOULD issue an AR-AR CARD Request to the respective CARs if complete capability information of a CAR is not available in the current AR's CAR table, or if such information is expired or about to expire. The AR-AR CARD Request message format is defined in Section 5.2.2. The sequence number on the AR-AR interface starts with zero when the AR reboots. The sending AR MUST increment the sequence number in the CARD Request by one each time it sends a CARD Request message.
CARの完全な能力情報は、現在のARのCARテーブルでは利用できない場合、またはそのような情報は、有効期限が切れたか、期限切れになる場合ARは、各かごにAR-ARカード要求を発行する必要があります。 AR-AR CARD要求メッセージフォーマットはセクション5.2.2で定義されています。 ARの再起動時にAR-ARインタフェース上のシーケンス番号はゼロから始まります。送信側ARは、CARD要求メッセージを送信する1ずつCARD要求にシーケンス番号をインクリメントしなければなりません。
The AR MAY append its own capabilities, which are encoded as attribute-value pairs and encapsulated with the Capability Container message parameter, to the released AR-AR CARD Request. If the AR-AR CARD Request conveys the current AR's capabilities to the CAR, the associated Capability Container can have any value set for the Context-ID, as there is no need for the receiving CAR to process this field due to the absence of an L2 ID and an Address sub-option. Furthermore, the current AR MAY set the P-flag in the Capability Container sub-option to inform the CAR about its own capability to perform CARD protocol message piggybacking.
ARが解除AR-ARカードリクエストに、属性値ペアとして符号化と機能のコンテナメッセージパラメータでカプセル化されている独自の機能を追加してもよい（MAY）。 AR-ARカードリクエストがCARに現在のARの機能を伝える場合は、このフィールドを処理する受信CARの必要がないよう、関連する機能のコンテナが原因が存在しないために、コンテキスト-IDに設定された任意の値を持つことができますL2のIDとアドレスサブオプション。さらに、現在のARはCARDプロトコルメッセージのピギーバックを実行するために、自身の能力についてCARを通知する機能コンテナサブオプションでPフラグを設定してもよいです。
Optionally, a current AR MAY append the Preferences sub-option to the AR-AR CARD Request to obtain only capability parameters of interest from a CAR.
必要に応じて、現在のARはCARからの関心の唯一の能力パラメータを取得するためにAR-ARカードリクエストに設定サブオプションを追加するかもしれません。
Upon receipt of the AR-AR CARD Reply, sent by the CAR in response to the previously sent request, the MN's current AR SHALL extract the capability information from the payload of the received message and store the received capabilities in its local CAR table. The lifetime of individual capabilities is to be set according to the lifetime indicated for each capability received. The values of the table entries' timeouts shall depend upon the nature of individual capabilities.
以前に送信された要求に応答してCARによって送信されたAR-ARのCARD応答を受け取ると、MNの現在のARは、受信したメッセージのペイロードから能力情報を抽出し、そのローカルCARテーブルの受信機能を格納SHALL。個々の機能の寿命は、受信した各機能について示さ寿命に応じて設定されるべきです。テーブルエントリタイムアウトの値は、個々の能力の性質に依存するものとします。
Optionally, CARs can send unsolicited CARD Reply messages to globally adjacent ARs if the configuration of their APs or capabilities changes dynamically. If the current AR receives an unsolicited CARD Reply message from a CAR for which there is an entry in its local CAR table, the current AR checks that the sequence number of the received CARD Reply has increased compared to that of the previously received unsolicited CARD Reply message, which has been sent from the same CAR. Then, the current AR can update its local CAR table according to the received capabilities. If a new CAR is added, an AR may receive a CARD Reply from a CAR that is not in its CAR table, or from a CAR that has rebooted. In this case, the sequence number is 0. The requirement that ARs share an IPsec security association, detailed in Section 6, ensures that an AR never accepts CARD information from an unauthenticated source.
必要に応じて、車は自分のAPまたは機能の構成が動的に変更された場合、隣接のARをグローバルに迷惑CARD返信メッセージを送信することができます。現在のARは、そのローカルCARテーブル内にエントリが存在しているためCARから受信CARD応答のシーケンス番号が以前に迷惑CARD応答を受信したのに比べて増加していることを現在のARの確認を求められていないCARD応答メッセージを受信した場合同じCARから送られてきたメッセージを、。その後、現在のARは、受信した能力に応じて、そのローカルCARテーブルを更新することができます。新しい車が追加された場合、ARはCARテーブルにない場合、または再起動したCARからCARからCARD応答を受信することができます。この場合、シーケンス番号のARは、IPsecセキュリティアソシエーションを共有0要件である、第6節で詳細、ARは、認証されていないソースからカード情報を受け入れないことを保証します。
Upon receipt of an AR-AR CARD Request, a CAR shall extract the sending AR's capabilities, if the sending AR has included its capabilities. The CAR SHALL store the received capabilities in its CAR table and set the timer for individual capabilities appropriately. The values of the table entries' timeouts depend on the nature of capabilities in the AR-AR CARD Reply message. The CAR must include the same sequence number in the AR-AR CARD Reply Message as that received in the AR-AR CARD Request Message. The AR-AR CARD Reply shall include the CAR's capabilities as list of attribute-value pairs in the Capability Container message parameter. If the sending AR has appended an optional Preferences sub-option, the CAR MAY perform capability filtering and send back only those capabilities of interest to the requesting AR, identified according to the
送信ARは、その機能が含まれている場合はAR-ARカード要求を受信すると、CARは、送信ARの機能を抽出するものとします。 CARは、CARテーブル内の受信能力を保存し、適切に個々の能力のためのタイマーを設定しなければなりません。テーブルエントリタイムアウトの値はAR-AR CARD Replyメッセージでの能力の性質に依存します。それはAR-AR CARD要求メッセージに受信したCARは、AR-AR CARD応答メッセージに同じシーケンス番号を含まなければなりません。 AR-ARカード返信は、能力コンテナメッセージパラメータの属性と値のペアのリストとしてCARの機能を含まなければなりません。送信ARは、オプション設定のサブオプションを付加した場合、CARはに従って同定、機能フィルタリングを実行し、要求ARに戻って興味のあるものだけの能力を送信することができ
Preferences sub-option. Because the AR-AR CARD Reply is based on a previously received AR-AR CARD Request, the CAR MUST set the U-flag of the AR-AR CARD Reply to 0.
環境設定のサブオプション。 AR-ARのCARD応答が以前に受信したAR-ARのCARD要求に基づいているため、CARが0にAR-ARのCARD応答のUフラグを設定しなければなりません。
Optionally, the CAR MAY send an unsolicited CARD Reply message to globally adjacent ARs if one or more of its capability parameters change. Each unsolicited CARD Reply message should have as destination address the adjacent AR's unicast address and must have the U-flag set. Consecutive unsolicited CARD Reply messages MUST have the sequence number incremented accordingly, starting with 0 when the AR boots.
必要に応じて、CARは、能力パラメータの一つ以上が変更された場合、隣接のARをグローバルに迷惑CARD Replyメッセージを送信することができます。各迷惑CARD応答メッセージは、宛先アドレスとして隣接ARのユニキャストアドレスを有するべきであり、Uフラグが設定されていなければなりません。連続した迷惑CARD応答メッセージは、0時にARブーツで始まる応じてインクリメントされたシーケンス番号を持っている必要があります。
CARD supports another mode of CAR information distribution, in which the capabilities are piggybacked on fast handover protocol messages. To allow MNs and ARs appending the ICMP-option type CARD Request and CARD Reply (Section 5.1.2) to the ICMP-type Fast Mobile IPv6 [Kood03] signaling messages, the MN and AR should know about the signaling peer's capability for CARD protocol message piggybacking. This requires dynamic discovery of piggybacking capability using the P-flag in the MN-AR CARD Request and the MN-AR CARD Reply message, as well as in the Capability Container message parameter. The format of these messages and parameters is described in Section 5.1.
カードは機能が高速ハンドオーバプロトコルメッセージに背負わされているCAR情報配信の別のモードをサポートしています。 MNとのARは、高速モバイルIPv6 [Kood03]シグナリングメッセージを、MNとARはCARDプロトコルのためのシグナリングピアの能力について知っておくべきICMPタイプとICMP-オプションタイプCARD要求とCARDリプライ（セクション5.1.2）を追加できるようにするにはメッセージ便乗。これは、動的MN-ARのCARD要求とMN-AR CARD応答メッセージにPフラグを使用して機能をピギーバックの発見、ならびに能力コンテナメッセージパラメータでを必要とします。これらのメッセージとパラメータのフォーマットは、セクション5.1に記載されています。
The MN sends the very first CARD Request to its current AR using the ICMP-type CARD main header for transport, as described in Section 4.2.1. If the MN supports CARD-protocol message piggybacking, the P-flag in this very first CARD Request message is set. On receipt of the CARD Request message, the current AR learns about the MN's piggybacking capability. To indicate its piggybacking capability, the AR sets the P-flag in the CARD Reply message. If the AR does not support piggybacking, all subsequent CARD-protocol messages between the MN and the AR are sent stand-alone, using the CARD main header. If both nodes (the MN and its current AR) support CARD-protocol message piggybacking, subsequent CARD protocol messages can be conveyed as an option via the Fast Mobile IPv6 Router Solicitation for Proxy (RtSolPr) and Proxy Router Advertisement (PrRtAdv) messages. During the CARD process, an MN learns about CARs' piggybacking capability at the discovery phase, as the Capability Container (described in Section 5.1.3.4) also carries a P-flag. This allows the MN to perform CARD protocol message piggybacking immediately after a handover to a selected CAR, assuming that this CAR supports CARD protocol piggybacking.
セクション4.2.1で説明したようにMNは、輸送のためのICMPタイプのカードメインヘッダを使用して、現在のARに非常に最初のCARD要求を送信します。 MNがCARDプロトコルメッセージのピギーバックをサポートしている場合は、この非常に最初のCARD要求メッセージ内のP-フラグが設定されています。 CARD Requestメッセージを受信すると、現在のARはMNのピギーバッキング機能について学習します。そのピギーバック能力を示すために、ARはCARD応答メッセージにPフラグをセットします。 ARは、ピギーバックサポートしていない場合は、MNとAR間のすべての後続CARD-プロトコルメッセージはCARDメインヘッダを使用して、スタンドアローン送信されます。両方のノード（MNとその現在のAR）サポートCARDプロトコルメッセージ便乗した場合、その後のCARDプロトコルメッセージは、プロキシ（RtSolPrを）およびプロキシルータ広告（代理ルータ広告）メッセージのための高速モバイルIPv6ルータ要請を介してオプションとして搬送することができます。 （セクション5.1.3.4を参照）能力コンテナはまた、Pフラグを運ぶようにCARDプロセス中に、MNは、発見段階で車のピギーバック機能について学習します。これは、この車はCARDプロトコルピギーバックをサポートすると仮定すると、MNは、選択CARへのハンドオーバの直後にピギーバックCARDプロトコルメッセージを実行することを可能にします。
If a MN prefers the reverse address translation function of the Fast Mobile IPv6 protocol, it can use CARD protocol message piggybacking to retrieve only the CARs' capability information. To indicate that reverse address translation is not required, the piggybacked CARD Request message MUST have the A-flag set. This causes the current AR to append only Capability Container sub-options. To associate a Capability Container sent as a parameter of the CARD Reply message to the IP address for the appropriate CAR, the Context-ID of an individual Capability Container MUST be used as an index, pointing to the associated IP address in the PrRtAdv message options. The Context-ID of individual Capability Containers is set appropriately by the MN's current AR. Details about how individual Context-ID values can be associated with a particular IP address option of the PrRtAdv message is out of the scope of this document.
MNは、高速モバイルIPv6プロトコルの逆のアドレス変換機能を好む場合は、それだけで車の機能情報を取得するために便乗CARDプロトコルメッセージを使用することができます。逆アドレス変換が必要とされていないことを示すには、ピギーバックCARD Requestメッセージには、A-フラグを設定する必要があります。これは、能力コンテナのサブオプションを追加するために、現在のARの原因となります。適切なCARのIPアドレスへのCARD Replyメッセージのパラメータとして送信能力コンテナを関連付けるために、個々の能力コンテナのコンテキストIDを代理ルータ広告メッセージオプションに関連付けられたIPアドレスを指し、インデックスとして使用する必要があります。個々の能力コンテナのコンテキスト-IDは、MNの現在のARによって適切に設定されています。個々のコンテキスト-ID値が代理ルータ広告メッセージの特定のIPアドレスオプションに関連付けることができる方法についての詳細は、このドキュメントの範囲外です。
The MN-AR interface uses ICMP for transport. Because ICMP messages are limited to a single packet, and because ICMP contains no provisions for retransmitting packets if signaling is lost, the CARD protocol incorporates provisions for improving transport performance on the MN-AR interface. MNs SHOULD limit the amount of information requested in a single ICMP packet, as ICMP has no provision for fragmentation above the IP level.
MN-ARインタフェースは、輸送のためにICMPを使用しています。 ICMPメッセージが単一のパケットに制限されているため、およびICMPは、シグナリングが失われた場合、パケットを再送するための条項が含まれていないため、CARDプロトコルは、MN-ARインターフェイス上で輸送性能を向上させるための条項が組み込まれています。 ICMPはIPレベル以上断片化のための規定を持っていないとしてのMNは、単一のICMPパケットで要求される情報の量を制限する必要があります。
MNs and ARs use the Experimental ICMP-type main header [Ke04] when CARD protocol messages cannot be conveyed via ICMP-type Fast Mobile IPv6 [Kood03]. The MN-AR interface MUST implement and SHOULD use the CARD ICMP-type header for transport. If available, the MN-AR interface MAY use the ICMP-type Fast Mobile IPv6 [Kood03] for transport (Section 4.4).
CARDプロトコルメッセージは、ICMPタイプの高速モバイルIPv6 [Kood03]を介して伝達することができない場合のMNとのARは[KE04]実験ICMP型メインヘッダを使用します。 MN-ARインタフェースを実装しなければなりません、そして、輸送のためのCARD ICMP-Typeヘッダを使用するべきです。利用可能な場合、MN-ARインタフェースは、輸送のためのICMP型高速モバイルIPv6 [Kood03]（セクション4.4）を使用することができます。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- - - -
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|コード|チェックサム| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |サブタイプ|予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |オプション... + - + - + - + - + - + - + - + - + - + - + - + - - - -
IP Fields:
IPフィールド：
Source Address: An IP address assigned to the sending interface.
送信元アドレス：送信インタフェースに割り当てられたIPアドレス。
Destination Address: An IP address assigned to the receiving interface.
宛先アドレス：受信インターフェイスに割り当てられたIPアドレス。
Hop Limit: 255
ホップ制限：255
ICMP Fields:
ICMPフィールド：
Type: Experimental Mobility type (assigned by IANA for IPv4 and IPv6, see [Ke04]).
タイプ：実験モビリティタイプ（IPv4およびIPv6のためのIANAによって割り当てられ、[KE04]を参照）。
Code: 0
コード：0
Checksum: The ICMP checksum.
チェックサム：ICMPチェックサム。
Subtype: Experimental Mobility subtype for CARD; see [Ke04].
サブタイプ：CARDのための実験モビリティサブタイプ。 [KE04]を参照してください。
Reserved: This field is currently unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約：このフィールドは、現在使用されていません。これは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Valid Options:
有効なオプション：
CARD Request: The CARD Request allows entities to request CARD-specific information from ARs. To support processing of the CARD Request message on the receiver side, further sub-options may be carried, serving as input to the reverse address translation function and/or capability discovery function.
CARD要求：CARD要求は実体がのARからカード固有の情報を要求することができます。受信側のCARD要求メッセージの処理をサポートするために、さらにサブオプションは、逆アドレス変換機能及び/又は能力発見機能への入力として、実施することができます。
CARD Reply: The CARD Reply carries parameters, previously requested with a CARD Request, back to the sender of the CARD Request.
CARD返信：CARD返信が以前にバックカードのリクエストの送信者に、CARD要求で要求されたパラメータを、運びます。
Valid Sub-Options:
有効なサブオプション：
Support level is indicated in parentheses.
サポートレベルは括弧内に示されています。
Layer-2 ID (mandatory): The Layer-2 ID sub-option [5.1.3.1] carries information about the type of an access point as well as the Layer-2 address of the access point associated with the CAR whose IP address and capability information is to be resolved.
レイヤ2のID（必須）：レイヤ2のIDサブオプション[5.1.3.1]は、アクセスポイントのタイプならびにそのIPアドレスとCARに関連付けられているアクセスポイントのレイヤ2アドレスの情報を運び能力情報は、解決すべきです。
Capability Container (mandatory): The Capability Container sub-option carries information about a single CAR's capabilities. The format of this sub-option is described in Section 5.1.3.4.
能力コンテナ（必須）：能力コンテナのサブオプションは、単一のCARの機能についての情報を運びます。このサブオプションの形式は、セクション5.1.3.4に記載されています。
Address (mandatory): The Address sub-option carries information on an individual CAR's resolved IP address. The format of the Address sub-option is described in Section 5.1.3.5.
アドレス（必須）：アドレスサブオプション個々のCARの解決されたIPアドレスの情報を運びます。アドレスサブオプションの形式は、セクション5.1.3.5に記載されています。
Trusted Anchor (mandatory): The Trusted Anchor sub-option carries the name of a trusted anchor for which the MN has a certificate. The format of the Trusted Anchor sub-option is described in Section 5.1.3.6.
信頼アンカー（必須）：信頼されたアンカーサブオプションは、MNが証明書を持っている信頼できるアンカーの名前を運びます。信頼アンカーサブオプションの形式は、セクション5.1.3.6に記載されています。
Router Certificate (mandatory): The Router Certificate sub-option carries one certificate in the path for the current AR or for a CAR. The chain includes certificates starting at a trusted anchor, which the AR shares in common with the MN, to the router itself. The format of the Router Certificate sub-option is described in Section 5.1.3.7.
（必須）ルータ証明書：ルータ証明書サブオプションは、現在のARまたはCARのパス内の1つの証明書を運びます。チェーンは、ルータ自体にMNと共通の信頼できるアンカーから始まる証明書、ARの株式を、含まれています。ルータ証明書のサブオプションの形式は、セクション5.1.3.7に記載されています。
Preferences (optional): The Preferences sub-option carries information about attributes of interest to the requesting entity. Attributes are encoded according to the AVP encoding rule, which is described in Section 5.1.4. For proper settings of AVP Code and Data field, see Section 5.1.3.2. This sub-option is used only if optional capability pre-filtering is performed on ARs, and it provides only capabilities of interest to a requesting MN.
環境設定（オプション）：環境設定のサブオプションは、要求エンティティへの関心の属性に関する情報を運びます。属性は、セクション5.1.4に記載されているAVP符号化規則に従って符号化されます。 AVPコードとデータフィールドの適切な設定については、セクション5.1.3.2を参照してください。このサブオプションは、オプションの機能をプレフィルタリングがARの上で実行されている場合にのみ使用し、それが要求してMNへの関心の機能のみを提供しています。
Requirements (optional): The Requirements sub-option carries information about attribute-value pairs required for pre-filtering of CARs on the MN's current AR. This parameter conveys MN specific attribute-value pairs to allow the MN's current AR to send only information about CARs of interest back to the requesting MN. CARs are filtered on ARs according to the CARs' capability parameters and given policy or threshold, as encoded in the Requirements sub- option. Attribute-value pairs are encoded according to the AVP encoding rule, which is described in Section 5.1.4. Rules for proper setting of the AVP Code and Data field for the Requirements sub-option are described in Section 5.1.3.3.
要件（オプション）：要件のサブオプションは、MNの現在のARの自動車のプレフィルタリングのために必要な属性と値のペアについての情報を運びます。このパラメータは、MNの現在のARは、要求元MNへの関心のクルマの情報のみを送信することを可能にするためにMN特定の属性と値のペアを伝えます。車は車の能力パラメータに従ってアクセスルータ上で濾過し、要件サブオプションで符号化されるように、ポリシーまたはしきい値を与えられています。属性値のペアは、セクション5.1.4に記載されているAVP符号化規則に従って符号化されます。要件のサブオプションのAVPコードとデータフィールドの適切な設定のための規則は、セクション5.1.3.3で説明されています。
CARD Requests that fail to elicit a response are retransmitted. The initial retransmission occurs after a CARD_REQUEST_RETRY wait period. Retransmissions MUST be made with exponentially increasing wait intervals (doubling the wait each time). CARD Requests should be retransmitted until either a response (which might be an error) has been obtained or CARD_RETRY_MAX seconds have occurred. ARs MUST discard any CARD Requests having the same sequence number after CARD_RETRY_MAX seconds. If a CARD Reply spans multiple ICMP messages, the same sequence number MUST be used in each message.
応答を誘発することができないCARD要求が再送信されます。最初の再送がCARD_REQUEST_RETRY待機期間後に発生します。再送は、指数関数的に増加する待機間隔（待機たび倍加）を用いて行わなければなりません。 （エラーの可能性があります）応答のいずれかが得られているかCARD_RETRY_MAX秒が発生したまでカード要求を再送信する必要があります。 ARSがCARD_RETRY_MAX秒後に同じシーケンス番号を有する任意のカードの要求を捨てなければなりません。 CARD応答は、複数のICMPメッセージにまたがる場合、同じシーケンス番号は、各メッセージで使用されなければなりません。
MNs that retransmit a CARD Request use the same CARD sequence number. This allows the AR to cache its reply to the original request and then to send it again, should a duplicate request arrive. This cached information should only be held for a maximum of CARD_RETRY_MAX seconds after receipt of the request. Sequence numbers SHOULD be chosen randomly. Random sequence numbers avoid duplicates if MNs restart frequently and simplify sequence-number maintenance on both the MN and AR when MNs frequently appear and disappear due to movement between CARs.
CARD要求を再送信するMNは、同じカードのシーケンス番号を使用します。これは、ARは、元の要求への応答をキャッシュするようにして、再びそれを送信することができ、重複した要求が到着しなければなりません。このキャッシュされた情報は、要求を受領してCARD_RETRY_MAX秒の最大保持する必要があります。シーケンス番号はランダムに選ばれるべきです。 MNが頻繁に再起動するとのMNが頻繁に起因する車両間の動きに現れたり消えたりするときMNとARの両方にシーケンス番号のメンテナンスを簡素化する場合は、ランダムなシーケンス番号が重複を避けます。
All options are of the following form:
すべてのオプションは以下の形式です。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |Vers.| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|長さ| Versの。| ... | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +〜...〜+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Fields:
フィールド：
Type: 8-bit identifier of the type of option, assigned by IANA. See [Ke04] for CARD Request and CARD Reply values.
タイプ：オプションのタイプの8ビット識別子、IANAによって割り当てられます。 CARD要求とCARD返信の値について[KE04]を参照してください。
Length: 8-bit unsigned integer. The length of the option, including the type and length fields in units of 8 octets. The value 0 is invalid.
長さ：8ビットの符号なし整数。 8つのオクテット単位のタイプと長さフィールドを含むオプションの長さ。値0は無効です。
Vers.: 3-bit version code. For this specification, Vers.=1.
VERSは、3ビットのバージョンのコードを.:します。この仕様のために、Versの= 1。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |Vers.|P|C|A|T| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|長さ| Versの|。P | C | A | T |予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |シーケンス番号| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |サブオプション+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - -
Fields:
フィールド：
Type: Assigned by IANA for IPv4 and IPv6; see [Ke04].
タイプ：IPv4とIPv6のためにIANAによって割り当てられました。 [KE04]を参照してください。
Length: The length of the option in units of 8 octets, including the type and length fields as well as sub-options.
長さ：タイプと長さフィールド、ならびにサブオプションを含む8つのオクテット単位のオプションの長さ。
Vers.: 3-bit version code. For this specification, Vers.=1.
VERSは、3ビットのバージョンのコードを.:します。この仕様のために、Versの= 1。
Flags: P-flag: Indicates the CARD-protocol message
piggybacking capability of the CARD
Request message sender. A description
for proper use of this flag can be
found in Section 4.4 of this document.
C-flag: Indicates that the requesting entity is
also interested in associated CARs'
capabilities. If the MN wants the AR
to append CARs' capability parameters
to the CARD Reply in addition to
address information, the MN must set
this flag.
A-flag: Indicates that the requesting entity does NOT want the receiver of this message to perform reverse address translation. This flag is set if CARD protocol messages are piggybacked with a protocol that performs reverse address translation. For details, refer to Section 4.4 of this document.
フラグは：要求エンティティが逆のアドレス変換を実行するには、このメッセージの受信を望んでいないことを示します。 CARDプロトコルメッセージは、逆アドレス変換を行うプロトコルでピギーバックされる場合、このフラグが設定されています。詳細については、このドキュメントのセクション4.4を参照してください。
T-flag: Indicates that the requesting entity is interested in obtaining all certificates from the responder. This flag is only valid on the AR-AR interface.
T-フラグ：要求エンティティは、レスポンダからのすべての証明書を取得するに興味があることを示します。このフラグは、AR-ARインターフェイス上でのみ有効です。
The flag combination A=1 and C=0 is invalid, and the flag T=1 is invalid on the MN-AR interface. The AR MUST discard an invalid message and log an appropriate error message.
フラグ組合せA = 1、C = 0は無効であり、フラグT = 1は、MN-ARインタフェース上無効です。 ARは、無効なメッセージを破棄し、適切なエラーメッセージをログに記録しなければなりません。
Reserved: Initialized to zero, ignored on receipt.
予約：領収書の上で無視、ゼロに初期化されます。
Sequence Number: Allows requests to be correlated with replies.
シーケンス番号は：リクエストが回答と相関することができます。
Valid Sub-Options:
有効なサブオプション：
- L2 ID sub-option - Preferences sub-option - Requirements sub-option - Trusted Anchor sub-option
- L2 IDサブオプション - 環境設定のサブオプション - 要件のサブオプション - 信頼されたアンカーサブオプション
To ensure that requirements on boundary alignment are met, individual sub-options MUST meet the 64-bit boundary alignment requirements respectively. This will ensure that the entire CARD Request option meets the 8n alignment constraint.
境界整列で要件が満たされていることを確実にするために、個々のサブオプションは、それぞれ64ビット境界整列要件を満たさなければなりません。これは、カード全体のリクエストオプションが8Nアライメント制約を満たしていることを確認します。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |Vers.|P|U|L| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |タイプ|長さ| Versの|。P | U | L |予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |シーケンス番号| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |サブオプション+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - -
Fields:
フィールド：
Type: Assigned by IANA for IPv4 and IPv6 [Ke04].
タイプ：IPv4とIPv6 [KE04]のためにIANAによって割り当てられます。
Length: The length of the option in units of 8 octets, including the type and length fields as well as sub-options.
長さ：タイプと長さフィールド、ならびにサブオプションを含む8つのオクテット単位のオプションの長さ。
Vers.: 3-bit version code. For this specification, Vers.=1.
VERSは、3ビットのバージョンのコードを.:します。この仕様のために、Versの= 1。
Flags: P-flag: Indicates the CARD-protocol message
piggybacking capability of the CARD
Reply message sender. A description
for proper use of this flag can be
found in Section 4.4 of this document.
U-flag: Indicates an unsolicited CARD Reply.
This flag is only valid on the AR-AR
interface.
L-flag: Set if this message is the last message in a multiple ICMP message reply. This flag is only valid on the MN-AR interface.
Lフラグ：このメッセージは、複数のICMPメッセージの応答の最後のメッセージである場合に設定。このフラグは、MN-ARインターフェイス上でのみ有効です。
The flag U=1 on an AR-MN message is invalid. An invalid message should be discarded and an appropriate error message logged.
AR-MNメッセージにフラグU = 1は無効です。無効なメッセージは破棄され、適切なエラーメッセージがログに記録されなければなりません。
Reserved: Initialized to zero, ignored on receipt.
予約：領収書の上で無視、ゼロに初期化されます。
Sequence Number: Allows requests to be correlated with replies.
シーケンス番号は：リクエストが回答と相関することができます。
Valid Sub-Options:
有効なサブオプション：
- L2 ID sub-option - Capability Container sub-option - Address sub-option - Router Certificate sub-option
- L2 IDサブオプション - 能力コンテナサブオプション - 住所サブオプション - ルータの証明書のサブオプション
To ensure requirements on boundary alignment are met, individual sub-options MUST meet 64-bit boundary alignment requirements respectively. This will ensure that the entire CARD Request option meets the 8n alignment constraint.
境界整列に関する要件が満たされていることを確認するために、個々のサブオプションは、それぞれ64ビット境界位置合わせ要件を満たさなければなりません。これは、カード全体のリクエストオプションが8Nアライメント制約を満たしていることを確認します。
All sub-options are of the following form:
すべてのサブオプションは以下の形式です。
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-Option Type|Sub-Option Len | Sub-Option Data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-Option Type: 8-bit identifier of the type of option. The sub-options defined in this document are listed in the table below. The table also indicates on which interfaces the sub-option is valid.
サブオプションタイプ：オプションのタイプの8ビットの識別子。この文書で定義されたサブオプションは以下の表に記載されています。表はまた、その上にサブオプションが有効なインタフェースを示します。
Description Type Interface
| | / \
| | MN-AR AR-AR
---------------------------------------------------------------
L2 ID 0x01 x
Address 0x02 x
Capability Container 0x03 x x
Preferences 0x04 x x
Requirements 0x05 x
Trusted Anchor 0x06 x
Router Certificate 0x07 x x
Sub-Option-Length: 8-bit unsigned integer indicating the length of the sub-option, including the sub-option type and sub-option length fields. Sub-option lengths are in units of 8 octets, aligned on a 64-bit boundary. Sub-options that are shorter are padded with null octets; the extent of the padding is determined by the sub-option contents.
サブオプション長：サブオプションタイプとサブオプション長フィールドを含むサブオプションの長さを示す8ビットの符号なし整数。サブオプションの長さは64ビット境界で整列8つのオクテットの単位です。短いサブオプションはヌルオクテットで埋めています。パディングの程度は、サブオプションの内容によって決定されます。
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-Option Type|Sub-Option Len | Context-ID | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2-Type | L2 ID . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |サブオプションタイプ|サブオプションレン|コンテキストID |ステータスコード| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | L2-タイプ| L2のID。 。 。 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - -
Sub-Option Type: 0x01
サブオプションタイプ：0×01
Sub-Option Length: Length of the sub-option.
サブオプションの長さ：サブオプションの長さ。
Context-ID: Associates the L2 ID, IP address and other parameters that belong to the same AR IP address but are encoded in separate sub-options.
コンテキストID：L2 ID、IPアドレスと同じAR IPアドレスに属しているが、別々のサブオプションで符号化される他のパラメータは関連付け。
Status Code: This field allows ARs to inform a requesting entity about processing results for a particular L2 ID. The L2 ID sub-option MUST be sent back to the requesting entity with a CARD Reply message.
ステータスコード：このフィールドは、のARが特定のL2 IDの処理結果について要求エンティティに通知することができます。 L2 IDサブオプションは、CARD応答メッセージで要求エンティティに返送しなければなりません。
The following status codes are specified:
次のステータスコードが指定されています。
0x00: NONE - This value MUST be set when the L2 ID is included in a CARD Request.
0x00：NONE - L2 IDがCARD要求に含まれている場合、この値は設定しなければなりません。
0x01: CANDIDATE - MUST be set in a CARD Reply when a L2 ID sub-option is included with information about candidate APs' L2 IDs. Candidate L2 IDs are sent if the CARD Request did not include a specific L2 ID for resolution. If CANDIDATE is set, the AR MUST set the Context-ID field of individual parameters to a value that allows associated L2 ID, address, and capability information to be matched on the receiver side.
0×01：候補者は - L2 IDサブオプションは、候補APのL2 IDに関する情報に含まれている場合CARD応答に設定しなければなりません。 CARD要求は解決のための具体的なL2のIDが含まれていなかった場合は候補L2 IDが送信されます。候補が設定されている場合、ARは、受信側で一致する関連するL2のID、アドレス、および能力情報を可能にする値に各パラメータのコンテキストIDフィールドを設定しなければなりません。
0x02: MATCH - MUST be set in the CARD Reply to identify that this L2 ID matches previously resolved CAR information for a different L2 ID. If MATCH is set, the AR sets the Context-ID in the L2-ID sub-option to identify the matching previously resolved L2 ID.
0×02：MATCH - このL2 IDが異なるL2 IDのために以前に解決CAR情報と一致していることを識別するために、CARD応答に設定しなければなりません。 MATCHが設定されている場合、ARは、以前L2 ID解決マッチングを識別するためにL2-IDサブオプションのコンテキスト-IDを設定します。
0x03: RESOLVER ERROR - MUST be set in the CARD Reply if the L2 ID cannot be resolved. The AR sets this value for the Status Code in the returned L2 ID sub-option.
0x03のレゾルバ誤差は - L2 IDが解決できない場合は、カードの返信に設定しなければなりません。 ARは、返されたL2 IDサブオプションでステータスコードのために、この値を設定します。
L2 type: Indicates the interface type. Allocated by IANA [Ke04].
L2タイプ：インターフェイスタイプを示します。 [KE04] IANAによって割り当てられました。
L2 ID: The variable length Layer-2 identifier of an individual CAR's access point. The length without padding is determined by the L2 type.
L2番号：個人CARのアクセスポイントの可変長レイヤ2識別子。パディングなしの長さはL2タイプによって決定されます。
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-Option Type|Sub-Option Len | Preferences +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-Option Type: 0x04
サブオプションタイプ：0×04
Sub-Option Length: Length of the sub-option.
サブオプションの長さ：サブオプションの長さ。
Preferences: List of capability attribute values (see Section 5.1.4).
設定：能力属性値の一覧（セクション5.1.4を参照してください）。
Only ATTRIBUTE (AVP Code; see Section 5.1.4) fields MUST be present and set for individual capabilities, which are of interest to the requesting entity. The LIFETIME and VALUE (Data) indicator will not be processed and can be omitted. The AVP LENGTH indicator is also not present, as the preferences are indicated only with a list of 16-bit encoded ATTRIBUTE fields. If 64-bit boundary alignment requirements cannot be met with the list of ATTRIBUTE values, padding the missing 16-bit MUST be done with an ATTRIBUTE value of 0x0000. An ATTRIBUTE code of 0x0 is reserved so that the end of the ATTRIBUTE code list can be determined when an ATTRIBUTE value of 0x0 is read.
専用属性（AVPコードは、セクション5.1.4を参照）のフィールドが存在し、要求エンティティにとって関心のある個々の能力、に設定する必要があります。寿命およびVALUE（データ）インジケータが処理されず、省略することができます。嗜好のみ16ビットの符号化属性フィールドのリストで示されたようにAVP長さインジケータは、また存在しません。 64ビット境界位置合わせ要件が欠落して16ビットをパディング属性値のリストを満たすことができない場合が0x0000の属性値を用いて行われなければなりません。 0x0の属性値が読み込まれたとき属性コードリストの終わりを決定することができるようには0x0の属性コードが予約されています。
The use of the Preferences sub-option is optional and is for optimization purposes.
環境設定のサブオプションの使用はオプションであり、最適化の目的のためです。
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-Option Type|Sub-Option Len | Requirements +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-Option Type: 0x05
サブオプションタイプ：0×05
Sub-Option Length: Length of the sub-option.
サブオプションの長さ：サブオプションの長さ。
Requirements: AVP-encoded requirements (see Section 5.1.4)
要件：AVP-エンコード要件（セクション5.1.4を参照してください）
AVPs MUST be encoded according to the rule described in Section 5.1.4. Both the ATTRIBUTE (AVP Code) and VALUE (Data) fields MUST be present and set appropriately. The end of the Requirements list can be determined when an ATTRIBUTE value of 0x0 is read.
AVPは、セクション5.1.4に記載の規則に従って符号化されなければなりません。 ATTRIBUTE（AVPコード）と値（データ）フィールドの両方が存在し、適切に設定しなければなりません。 0x0の属性値が読み込まれたとき要件リストの終わりを決定することができます。
The use of the Requirements sub-option is optional and is for optimization purposes.
要件のサブオプションの使用はオプションであり、最適化の目的のためです。
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-Option Type|Sub-Option Len | Context-ID |P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |サブオプションタイプ|サブオプションレン|コンテキストID | P |予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | AVPの+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - -
Sub-Option Type: 0x03
サブオプションタイプ：0×03
Sub-Option Length: Length of the sub-option.
サブオプションの長さ：サブオプションの長さ。
Context-ID: Associates the L2 ID, IP address, and other parameters that belong to the same AR IP address but are encoded in separate sub-options.
コンテキストID：L2 ID、IPアドレスを関連付け、同じAR IPアドレスに属しているが、別々のサブオプションで符号化される他のパラメータ。
Flags: P-flag: Indicates piggybacking capability of the CAR whose capabilities are conveyed in this Capability Container. This flag allows an MN to know after a CARD process whether a selected new AR can perform piggybacking.
フラグ：P-フラグ：機能この機能のコンテナで搬送されているCARの便乗能力を示します。このフラグは、MNは、選択された新しいARは、ピギーバックを実行できるかどうかCARD工程の後に知ることができます。
Reserved: Initialized to zero, ignored on receipt.
予約：領収書の上で無視、ゼロに初期化されます。
AVPs: AVPs are a method of encapsulating capability information relevant for the CARD protocol. See Section 5.1.4 for the AVP encoding rule and list parsing.
AVP：のAVPは、カードプロトコルに関連する機能情報をカプセル化する方法です。 AVP符号化規則およびリストの解析については、セクション5.1.4を参照してください。
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-Option Type|Sub-Option Len | Context-ID | Address Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |サブオプションタイプ|サブオプションレン|コンテキストID |アドレスタイプ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |住所 。 。 。 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - - - -
Sub-Option Type: 0x02
サブオプションタイプ：0×02
Sub-Option Length: Length of the sub-option. For IPv4, the length is 1 (8 octets); for IPv6 the length is 3 (24 octets).
サブオプションの長さ：サブオプションの長さ。 IPv4の場合、長さは1（8つのオクテット）です。 IPv6の長さは3（24オクテット）です。
Context-ID: Associates the L2 ID, IP address, and other parameters that belong to the same AR IP address but are encoded in separate sub-options.
コンテキストID：L2 ID、IPアドレスを関連付け、同じAR IPアドレスに属しているが、別々のサブオプションで符号化される他のパラメータ。
Address Type: Indicates the type of the address.
アドレスタイプは：アドレスのタイプを示します。
0x01 IPv4
0x02 IPv6
Address: The Candidate Access Router's IP address.
住所：候補アクセスルータのIPアドレス。
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-Option Type|Sub-Option Len | Component | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Trusted Anchor Name +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -
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-Option Type: 0x06
サブオプションタイプ：0x06で
Sub-Option Length: Length of the sub-option.
サブオプションの長さ：サブオプションの長さ。
Reserved: Initialized to zero, ignored on receipt.
予約：領収書の上で無視、ゼロに初期化されます。
Component: A 2 octet unsigned integer field set to 65,535 if the sender desires to retrieve all the certificates in the certification path. Otherwise, it is set to the component identifier corresponding to the certificate that the receiver wants to retrieve.
コンポーネント：送信者が証明書パス内のすべての証明書を取得することを希望する場合は2オクテット符号なし整数フィールドが65,535に設定されています。それ以外の場合は、受信機が取得したい証明書に対応するコンポーネント識別子に設定されています。
Trusted Anchor Name: DER encoding for the X.501 name of certification path component(see [Arkko04] for more detail on certification path component name encoding).
信頼アンカー名：認証パス成分のX.501名のDER符号化（認証パスコンポーネント名のエンコードについて詳しくは、[Arkko04]参照）。
A CARD Request message containing Trusted Anchor sub-options MUST NOT contain any other sub-options, except for a single L2 ID sub-option identifying the AP of interest.
信頼アンカーサブオプションを含むCARD要求メッセージは、対象のAPを識別する単一L2 IDサブオプションを除いて、任意の他のサブオプションを含んではなりません。
Trusted anchor sub-options SHOULD be retransmitted for individual components not received within CARD_REQUEST_RETRY seconds, rather than retransmitting a request for the whole list. Subsequent retransmissions SHOULD take into account any received options and only request those that have not been received.
信頼されたアンカーサブオプションではなく、全体のリストの要求を再送信するよりも、CARD_REQUEST_RETRY秒以内に受信されない個々のコンポーネントのために再送されるべきです。後続の再送信は、アカウントに任意の受信オプションを取るだけで受信されていないものを要求する必要があります。
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-Option Type|Sub-Option Len | Context-ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | All Components | Component | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Certificate... | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |サブオプションタイプ|サブオプションレン|コンテキストID |予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |すべてのコンポーネント|コンポーネント| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | | + + |証明書... | + + | | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |パディング... | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
Sub-Option Type: 0x07
サブオプションタイプ：0x07の
Sub-Option Length: Length of the sub-option.
サブオプションの長さ：サブオプションの長さ。
Context-ID: Associates the L2 ID, IP address and other parameters that belong to the same AR IP address but are encoded in separate sub-options.
コンテキストID：L2 ID、IPアドレスと同じAR IPアドレスに属しているが、別々のサブオプションで符号化される他のパラメータは関連付け。
Reserved: Initialized to zero, ignored on receipt.
予約：領収書の上で無視、ゼロに初期化されます。
All Components: 2 octet unsigned integer giving the total number of certificates in the certification path.
すべてのコンポーネント：証明書パス内の証明書の総数を与える2オクテットの符号なし整数。
Component: 2 octet unsigned integer giving the location of this certificate in the certification path.
成分：証明書パスにこの証明書の場所を与える2オクテットの符号なし整数。
Certificate: Variable-length field containing the X.509v3 router certificate encoded in ASN.1 (see [Arkko04] for more detail on a certificate profile that includes encoding).
証明書：ASN.1でエンコードされたX.509v3ルータの証明書を含む可変長フィールド（符号を含む証明書プロファイルについて詳しくは、[Arkko04]参照）。
Padding: Variable-length field making the option length a multiple of 8, beginning after the ASN.1 encoding of the certificate and continuing to the end of the option, as specified by the Length field.
パディング：可変長フィールド長さフィールドで指定され、証明書のASN.1符号化の後に始まり、オプションの終わりまで続く、オプションの長さを8の倍数になっています。
A CARD Reply containing a Router Certificate sub-option MUST NOT include more than one such sub-option, and the CARD Reply MUST contain the matching L2 ID sub-option and router Address sub-option for the router possessing the chain with the Context-ID field set to a nonzero value, and with no other sub-options. Any other sub-options included in a CARD Reply SHOULD be ignored. If the reply spans multiple ICMP messages, the L2 ID sub-option and router Address sub-option MUST be included in the first message sent, and the Context-ID field in the Router Certificate sub-options in all the messages MUST be set to the same value as that in the L2 ID and Address sub-options. The replying AR SHOULD order the returned certification path so that the certificate immediately after the trust anchor in the path is the first certificate sent, in order to allow immediate verification. The trust anchor certificate itself SHOULD NOT be sent.
ルータ証明書のサブオプションを含むCARD返信は、複数のそのようなサブオプションを含んではならない、とCARD返信は、コンテキストにチェーンを持つルータのマッチングL2 IDサブオプションおよびルータアドレスサブオプションを含まなければなりませんIDフィールドがゼロ以外の値に設定し、ノー他のサブオプションを有します。 CARD返信に含まれ、他のサブオプションは無視されるべきです。応答が複数のICMPメッセージをまたがる場合、L2 IDサブオプションおよびルータアドレスサブオプションは、すべてのメッセージにルータ証明書のサブオプションで送信された最初のメッセージ、およびコンテキストIDフィールドに含まれなければならないに設定しなければなりません。 L2のIDとアドレスサブオプションと同じ値。証明書のように返答するARは、パス内のトラストアンカーが即時検証を可能にするために、送信された最初の証明書である直後に返された証明書パスを注文する必要があります。トラストアンカー証明書自体を送るべきではありません。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | AVP Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Lifetime | Data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | AVPコード| AVPの長さ|予約| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |生涯属性|データ。 。 。 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - - -
AVP Code: Identifies the attribute uniquely. The AVP Code 0x0000 is reserved and MUST NOT be assigned to a capability.
AVPコード：一意属性を識別します。 AVPコード0000が予約されており、機能に割り当てることはできません。
AVP Length: The 2 octet AVP length field indicates the number of octets in this AVP, including the AVP Code, AVP Length, Reserved, Lifetime, and Data fields.
AVPの長さ：2オクテットAVPの長さフィールドはAVPコード、AVP長、予約済み、寿命、およびデータフィールドを含む。このAVPのオクテットの数を示します。
Reserved: Initialized to zero, ignored on receipt.
予約：領収書の上で無視、ゼロに初期化されます。
Lifetime: Specifies the lifetime of the encoded capability in seconds. In the case of a static capability, the Lifetime field MUST be set to the maximum value (0xffff), which indicates that the lifetime of this capability parameter never expires. A lifetime value of 0x0000 deletes a capability entry.
生涯：秒でエンコードされた機能の存続期間を指定します。静的能力の場合には、ライフタイムフィールドは、この能力パラメータの寿命が期限切れにならないことを示し、最大値（0xFFFFの）に設定しなければなりません。 0000の寿命値は、能力エントリを削除します。
Data: This variable-length field has the Value of the capability attribute encoded.
データ：この可変長フィールドには、エンコードされた能力属性の値を持っています。
Because an AVP Code of 0x0 is reserved, it can be used by the sub-option list parsing to determine when the end of a list of Capabilities has been reached and where the sub-option padding starts. AVPs themselves are not zero padded.
0x0のAVPコードが予約されているので、機能のリストの末尾に到達し、ここで、サブオプションのパディングが開始されたときを決定するために、サブオプションのリストの解析で使用することができます。自身はゼロでパディングされていないのAVP。
Note: This document provides no detailed information on how to encode the individual capability attribute values, which is to be encoded in the Data field. Details on the interpretation of individual capability parameters are out of the scope of this document.
注意：この文書は、個々の能力をエンコードするデータフィールドに符号化されるべきである、属性値をする方法についての詳細な情報を提供していません。個々の能力パラメータの解釈についての詳細は、この文書の範囲外です。
Because the types of access networks in which CARD might be useful are not currently deployed or, if they have been deployed, have not been extensively measured, it is difficult to know whether congestion will be a problem for inter-router CARD. Part of the research task in preparing CARD for consideration as a candidate for possible standardization is to quantify this issue. However, in order to avoid potential interference with production applications (should a prototype CARD deployment involve running over the public Internet), it seems prudent to recommend a default transport protocol that accommodates congestion.
CARDが有用である可能性のあるアクセスネットワークの種類は、現在、それらは広範囲に測定されていない、展開されている場合は、展開したりしていないので、輻輳がルータ間CARDのための問題になるかどうかを知ることは困難です。可能な標準化のための候補として検討するためのカードを製造する際に、研究課題の一部は、この問題を定量化することです。しかし、本番アプリケーション（プロトタイプカードの展開は、公共のインターネット上で動作して関与させるべきである）との潜在的な干渉を避けるために、混雑を収容し、デフォルトのトランスポートプロトコルをお勧めするのが賢明と思われます。
This suggests that implementations of CARD MUST support and that prototype deployments of CARD SHOULD use the Stream Control Transport Protocol (SCTP) [Stew00] as the transport protocol between routers, especially if deployment over the public Internet is contemplated. SCTP supports congestion control, fragmentation, and partial retransmission based on a programmable retransmission timer. SCTP also supports many advanced and complex features, such as multiple streams and multiple IP addresses for failover, that are not necessary for experimental implementation and prototype deployment of CARD. The use of these SCTP features for CARD is not recommended at this time.
これは、カードの実装がサポートしなければならないとカードのプロトタイプ展開は、公共のインターネット上で展開が企図されている場合は特に、ルータ間のトランスポートプロトコルとしてストリーム制御伝送プロトコル（SCTP）Stew00]を使用する必要があることを示唆しています。 SCTPは、輻輳制御、断片化、およびプログラマブル再送タイマに基づいて部分的に再送信をサポートしています。 SCTPは、カードの実験的な実装とプロトタイプの展開に必要とされないように複数のストリームとフェイルオーバーのために複数のIPアドレスなど、多くの高度で複雑な機能を、サポートしています。カードのこれらのSCTP機能を使用することは、現時点では推奨されません。
The SCTP Payload Data Chunk carries the CARD messages. CARD messages on the inter-router interface consist of just the CARD Request or CARD Reply options. The User Data part of each SCTP message contains the CARD option for the message type. For instance, a CARD Reply message is constructed by including the CARD Reply option and all the appropriate sub-options within the User Data part of an SCTP message.
SCTPペイロードデータチャンクは、カードのメッセージを運びます。ルータ間のインターフェイス上のカードのメッセージはちょうどCARD要求やカード返信オプションで構成されています。各SCTPメッセージのユーザデータ部には、メッセージタイプのカードオプションが含まれています。例えば、CARD応答メッセージは、カード返信オプションとSCTPメッセージのユーザデータ部内のすべての適切なサブオプションを含めて構成されています。
A single stream is used for CARD with in-sequence delivery of SCTP messages. Each message, unless fragmented, corresponds to a single CARD query or response. Unsolicited CARD Reply messages can also be sent to peers to notify them of changes in network configuration or capabilities. A single stream provides simplicity. Use of multiple streams to prevent head-of-line blocking is for future study. Since timeliness is not an issue with inter-router CARD, and since there being more than one CARD transaction between two routers active at any one time is unlikely, having ordered delivery simplifies the implementation. The Payload Protocol Identifier in the SCTP header is 'CARD'. CARD uses the Seamoby SCTP port number [Ke04].
単一ストリームは、SCTPメッセージのインシーケンス送達とCARDのために使用されます。各メッセージは、断片化されない限り、単一のカードクエリまたは応答に対応します。迷惑CARD応答メッセージは、ネットワークの構成や機能の変更を通知するためにピアに送信することができます。単一のストリームは、シンプルさを提供します。ヘッドオブラインブロッキングを防止するための複数のストリームを使用することは、将来の検討課題です。タイムリーはルータ間のカードとの問題ではなく、そこにいるので、任意の時点でアクティブ2つのルータ間に複数のカード取引であることはほとんどありませんので、注文した配信は、実装を簡素化します。 SCTPヘッダ内のペイロードプロトコル識別子は「CARD」です。 CARDは、[KE04] Seamoby SCTPポート番号を使用します。
The format of Payload Data Chunk taken from [Stew00] is shown in the following diagram.
【Stew00]から取られたペイロードデータチャンクのフォーマットは、次の図に示されています。
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0 | Reserved|U|B|E| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier S | Stream Sequence Number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Protocol Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / User Data (seq n of Stream S) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | = 0を入力し|予約| U | B | E |長さ| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | TSN | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |ストリーム識別子S |ストリームシーケンス番号N | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + |ペイロードプロトコル識別子| + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + \ \ /ユーザデータ（ストリームSの配列のN）/ \ \ + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
'U' bit The Unordered bit. MUST be set to 0 (zero).
'B' bit The Beginning fragment bit. See [Stew00].
'E' bit The Ending fragment bit. See [Stew00].
「E」はエンディングフラグメントビットビット。 [Stew00]を参照してください。
TSN Transmission Sequence Number. See [Stew00].
TSN送信シーケンス番号。 [Stew00]を参照してください。
Stream Identifier S Identifies the CARD stream.
ストリーム識別子Sは、カードストリームを識別します。
Stream Sequence Number n Sequence number. See [Stew00].
ストリームシーケンス番号Nシーケンス番号。 [Stew00]を参照してください。
Payload Protocol Identifier Set to 'CARD'.
「CARD」へのペイロードプロトコル識別子を設定。
User Data Contains the CARD message.
ユーザーデータは、カードのメッセージが含まれています。
In order to avoid generating congestion on startup, ARs MUST wait a random amount of time between 0 and CARD_STARTUP_WAIT seconds upon reboot before sending an AR-AR CARD Request to one of its CARs. An AR that receives a CARD Request from another AR that is not in its CAR table MUST NOT solicit the AR but rather MUST wait until the AR sends an unsolicited CARD Reply advertising the AR's information. An AR that is starting up MUST send unsolicited CARD Replies to all its CARs to make sure that their CAR tables are properly populated.
起動時に輻輳の発生を回避するためには、ARSがその車の1台にAR-ARカードリクエストを送信する前に、再起動時に0とCARD_STARTUP_WAIT秒の間でランダムな時間を待たなければなりません。そのCARテーブルにない他のARからCARD Requestを受信したARは、ARを求めてはならないのではなく、ARはARの情報を宣伝する迷惑CARD Replyを送信するまで待たなければなりません。起動されたARは、そのCARテーブルが正しく装着されていることを確認するために、すべての車両に迷惑CARDの返信を送らなければなりません。
The frequency of unsolicited CARD Reply messages MUST be strictly limited to CARD_MIN_UPDATE_INTERVAL, in order to avoid overwhelming CARs with traffic. ARs are free to discard messages that arrive more frequently.
迷惑CARD返信メッセージの頻度は、厳密にトラフィックで圧倒的な自動車を避けるために、CARD_MIN_UPDATE_INTERVALに限定されなければなりません。 ARSがより頻繁に届くメッセージを破棄するのは自由です。
If a CARD deployment will never run over the public Internet, and if it is known that congestion is not a problem in the access network, alternative transport protocols MAY be appropriate vehicles for experimentation. Implementations of CARD MAY support UDP for such purposes. In that case, the researcher MUST be careful to accommodate good Internet transport protocol engineering practices, such as using retransmits with exponential backoff. In addition, whether SCTP is an appropriate transport protocol for all inter-router CARD operations is an open research question. Investigation of this issue (for example, to determine whether a lighter-weight protocol might be more appropriate than SCTP) may be of interest to some researchers.
カードの展開は、公共のインターネット上で実行されることはありません、それは輻輳がアクセスネットワークに問題がないことが知られている場合、代替のトランスポートプロトコルは、実験のために適切な車かもしれ。場合CARDの実装は、そのような目的のためにUDPをサポートするかもしれません。その場合には、研究者は、このような指数バックオフして再送を使用するなど、優れたインターネットトランスポートプロトコルエンジニアリングの実践を、対応するために注意しなければなりません。また、SCTPは、すべてのルータ間CARD操作のための適切なトランスポートプロトコルであるかどうか、オープンな研究の質問です。この問題の調査は、いくつかの研究者に関心のある（例えば、軽量プロトコルはSCTPよりも適切であるかもしれないかどうかを判断します）。
The AR-AR interface MUST insert the CARD Request option and CARD Reply option directly into the body of the SCTP User Data field. The sequence number for the CARD Request on the AR-AR interface MUST be initialized to zero when the AR reboots, and MUST be incremented every time a CARD Request message is sent. The replying AR MUST include a sequence number from the CARD Request in the CARD Reply. If an unsolicited CARD Reply is sent, the sending AR MUST increment the sequence number. Sequentially increasing sequence numbers allows the receiving AR to determine whether the information has already been received.
AR-ARインタフェースは、SCTPのユーザデータフィールドの本体に直接CARD要求オプションとCARD返信オプションを挿入しなければなりません。 AR-ARインタフェース上CARD要求のシーケンス番号は、ARの再起動時にゼロに初期化されなければならない、とCARD要求メッセージが送信されるたびにインクリメントされなければなりません。返信ARはCARD応答でCARD要求からシーケンス番号を含まなければなりません。迷惑CARD返信が送信された場合、送信側ARは、シーケンス番号を増加しなければなりません。シーケンス番号を増やす順次受信AR情報が既に受信されたかどうかを決定することを可能にします。
On the AR-AR interface, the Capability Container parameter is used to convey capabilities between ARs. Optionally, the Preferences parameter can be used for capability pre-filtering during the inter-AR capability discovery procedure. Payload types and encoding rules are the same as those described for the respective sub-option types in Section 5.1 for the MN-AR interface. The same TLV-encoded format is used to attach the options as payload to the protocol main header. Additionally, an AR can set the T flag in the CARD Request header in order to obtain the certificates for the CAR. The description of sub-options in Section 5.1.3 includes information on what flag settings are prohibited on the AR-AR interface.
AR-ARインタフェース上、能力コンテナパラメータは、アクセスルータの間で機能を伝えるために使用されます。必要に応じて、環境設定パラメータは、インター-AR機能発見手順の間に能力のプレフィルタリングのために使用することができます。ペイロードタイプと符号化規則は、MN-ARインタフェースについては、セクション5.1に各サブオプションのタイプについて説明したものと同様です。同じTLV符号化フォーマットは、プロトコルのメインヘッダにペイロードとしてオプションを取り付けるために使用されます。また、ARはCARの証明書を得るために、CARD要求ヘッダ内のTフラグを設定することができます。セクション5.1.3におけるサブオプションの説明は、AR-ARインタフェース上禁止されているもののフラグ設定に関する情報を含みます。
The veracity of the CARD protocol depends on the ability of an AR to obtain accurate information about geographically neighboring ARs, and to provide accurate information about its own APs and capabilities to other ARs. The CARD protocol described in the body of this document does not contain any support for determining the AR-to-AP mapping or capabilities, either for a specific AR or for a CAR. Therefore, methods for determining the accuracy of the information exchanged between ARs are out of scope for the base CARD protocol. The appendices of this document describe procedures for discovering the identities of the geographically adjacent ARs and APs (including capabilities) and discuss relevant security considerations. Alternatively, this information could be statically configured into the AR.
CARDプロトコルの信憑性は、地理的に近隣のARに関する正確な情報を得るためのARの能力に依存し、他のARに、自身のAPと機能に関する正確な情報を提供します。本文書の本文に記載のCARDプロトコルは、特定のARまたはCARのいずれかのため、AR対APマッピングまたは機能を決定するための任意の支持体を含んでいません。したがって、アクセスルータ間で交換される情報の正確さを決定するための方法は、ベースCARDプロトコルの範囲外です。このドキュメントの付録には、（機能を含む）、地理的に隣接のARとAPのアイデンティティを発見するための手順を説明し、関連するセキュリティの考慮事項について説明します。あるいは、この情報は、静的にARに構成することができます。
CARD contains support allowing ARs to exchange capability information. If this protocol is not protected from modification, a malicious attacker can modify the information. Also, if the information is delivered in plain text, a third party can read it.
CARDは、のARが能力情報を交換できるようにするサポートが含まれています。このプロトコルは、変更から保護されていない場合は、悪意のある攻撃者が情報を変更することができます。情報がテキスト形式で配信された場合も、第三者がそれを読むことができます。
To prevent the information from being compromised, the CARD messages between ARs MUST be authenticated. The messages also SHOULD be encrypted for privacy of the information, if required. Confidentiality might be required if the traffic between two ARs in an operator's network traversed the public Internet, for example.
危険にさらされているから情報を防ぐために、アクセスルータ間のCARDメッセージは認証されなければなりません。必要に応じてメッセージも、情報のプライバシーのために暗号化する必要があります。事業者のネットワーク内の2つのAR間のトラフィックは、例えば、公衆インターネットを横断した場合に機密性が必要になることがあります。
Two ARs engaging in the CARD protocol MUST use IKE [HarCar98] to negotiate an IPsec ESP security association for message authentication. If confidentiality is desired, the two ARs MUST additionally negotiate an ESP security association for encryption. Replay protection SHOULD also be enabled with IKE. To protect CARD protocol messages between ARs, IPsec ESP [AtKe98] MUST be used with a non-null integrity protection and origin authentication algorithm and SHOULD be used with a non-null encryption algorithm for protecting the confidentiality of the CARD information.
CARDプロトコルに従事二つのARは、メッセージ認証のためのIPsec ESPセキュリティアソシエーションをネゴシエートするIKE [HarCar98]を使用しなければなりません。機密性が要求される場合は、2つのARは、さらに、暗号化のためのESPセキュリティアソシエーションをネゴシエートする必要があります。リプレイ保護もIKEを有効にする必要があります。ルータ間CARDプロトコルメッセージを保護するために、IPsecのESPは、[AtKe98] null以外の完全性保護と原点の認証アルゴリズムを使用する必要があり、カード情報の機密性を保護するためのnull以外の暗号化アルゴリズムで使用する必要があります。
An AR can provide the certificates for its CARs if the certificates are available. The AR requests certificates from its CARs by setting the T flag in the CARD Request message. All certificates are sent.
証明書が利用可能である場合にARは、その車のための証明書を提供することができます。 ARは、CARD要求メッセージにTフラグを設定することによって、そのカーから証明書を要求します。すべての証明書が送信されます。
If CARD is used to exchange information between different administrative domains, additional security policy issues may apply. Such issues are out of the scope of this document. Use of CARD between administrative domains is not recommended at this time, until the policy issues involved are more thoroughly understood.
カードが異なる管理ドメイン間で情報を交換するために使用されている場合は、追加のセキュリティポリシーの問題が適用される場合があります。このような問題は、この文書の範囲外です。関連する政策課題は、より徹底的に理解されるまで、管理ドメイン間CARDの使用は、この時点ではお勧めしません。
A malicious node can send bogus CARD Reply messages to MNs by masquerading as the AR. The MN MUST authenticate the CARD Reply messages from the AR. Since establishing an IPSec security association between the MN and AR is likely to be a performance issue, IKE is not an appropriate mechanism for setting up the security association. Instead, the SEND security association is used [Arkko04]. ARs MUST include a SEND Signature Option on CARD Reply messages. The format of the signature option is the same for both IPv4 and IPv6 CARD, though SEND itself is only defined for IPv6. A Mobile IPv4 ICMP Foreign Agent Advertisement option type code for the SEND signature option [Ke04] has been allocated.
悪意のあるノードは、ARを装っでのMNに偽のCARD返信メッセージを送信することができます。 MNは、ARからCARD返信メッセージを認証しなければなりません。 MN間のIPSecセキュリティアソシエーションを確立し、ARは、パフォーマンスの問題である可能性が高いので、IKEはセキュリティアソシエーションを設定するための適切なメカニズムではありません。代わりに、SENDセキュリティアソシエーションは、[Arkko04]使用されます。 ARはCARD返信メッセージのSEND署名オプションを指定する必要があります。署名オプションのフォーマットは、IPv4とIPv6のカードの両方に対して同じである、しかし自分自身を送信IPv6のみのために定義されています。 SEND署名オプション[KE04]をモバイルIPv4 ICMPフォーリンエージェント広告オプションタイプコードが割り当てられています。
No authentication is required for CARD Requests since CARD information is provided by the AR to optimize link access. In contrast, CARD Reply authentication is required because a bogus AR could provide the MN with CARD information that would lead the MN to handover to a bogus router, which could steal traffic or propagate a denial of service attack on the MN. The asymmetry of the authentication requirement is the same as that involving Router Advertisements in IPv6 router discovery [Arkko04].
カード情報は、リンクアクセスを最適化するために、ARによって提供されているので認証はCARD要求のために必要とされません。偽のARがトラフィックを盗むか、MN上のサービス拒否攻撃を伝播する可能性が偽のルータへのハンドオーバをMNにつながるカード情報をMNに提供する可能性があるためこれとは対照的に、CARD返信認証が必要です。認証要件の非対称性は、[Arkko04] IPv6ルータ発見でルータ広告を含むものと同じです。
Since CARD is a discovery protocol, confidentiality is not generally necessary on the MN-AR interface. In specific cases where different network operators share the same access network infrastructure, network operators may want to hide information about operator-specific capabilities for business reasons. The base CARD protocol contains no support for such cases. However, should such a case arise in the future, an AVP for an encrypted capability can be defined at that time.
CARDは、発見プロトコルであるため、機密性MN-ARインタフェース上で一般的に必要ではありません。異なるネットワーク事業者は、同じアクセスネットワークインフラストラクチャを共有する具体的な例では、ネットワークオペレータは、ビジネス上の理由から、オペレータ固有の機能についての情報を非表示にすることがあります。ベースCARDプロトコルは、このような場合のためのサポートが含まれていません。しかし、そのような場合は、暗号化機能のためのAVPは、その時点で定義することができ、将来的に発生する必要があります。
Because SEND is only available in IPv6, the procedures for obtaining certificates differ depending on whether CARD is used with IPv4 or IPv6. In IPv6, when the MN receives a CARD reply with signature from an AR for which it does not have a certificate, it SHOULD use SEND DCS/DCA to obtain the AR's certificate chain. ARs MUST be configured with a certification path for this purpose, and MNs MUST be configured with a set of certificates for shared trusted anchors to allow verification of the AR certificates. An MN may not necessarily need to use Cryptographically Generated Addresses (CGAs) with CARD, so CGA support is OPTIONAL for CARD. A certificate profile for ARs is described in the SEND specification [Arkko04].
SENDは、IPv6にのみ利用可能であるため、証明書を取得するための手順は、カードはIPv4またはIPv6で使用されるかどうかに応じて異なります。 MNは、それが証明書を持たないため、ARから署名付きCARD応答を受信したIPv6においては、ARの証明書チェーンを取得するためにDCS / DCAを送り使用すべきです。 ARは、この目的のために証明書パスで構成されなければならない、とのMNは、AR証明書の検証を可能にするための共有、信頼アンカーのための証明書のセットで構成されなければなりません。 CGAのサポートがカードの場合はオプションですので、MNは、必ずしも、カードを使って暗号的に生成されたアドレス（CGAs）を使用する必要はないかもしれません。アクセスルータの証明書プロファイルは、SEND仕様[Arkko04]に記載されています。
In IPv4, there is no DCS/DCA message for obtaining the certificate. If the MN does not have a certificate for the AR, the MN sends a CARD Request message containing the L2 ID of its current AP and one Trusted Anchor sub-option (Section 5.1.3.6) for each shared trusted anchor for which the MN has a certificate, to obtain the certification path for the current AR. The Component field of the Trusted Anchor sub-option is set to 65535 to indicate that the entire certification path is needed. No other options should be included in the request. The AR replies by sending a CARD Reply containing the L2 ID sub-option sent in the request, an Address sub-option for itself, and a Router Certificate sub-option (Section 5.1.3.7) containing one certificate in its certification path that matches one of the requested trust anchors, and no other sub-options, setting the Context-ID of all sub-options to match. The All Components field is set to the path length, and the Component field is set to the number of this component in the path. If the path is longer than one certificate, the AR sends the L2 ID sub-option and the Address sub-option in the first certificate and the other certificates in separate ICMP messages, due to the limitation on ICMP message length, with the same Context-ID set on each Route Certificate sub-option, and with the Component field properly set. The router SHOULD NOT send the trusted anchor's certificate and SHOULD send certificates in order from the certificate after the trusted anchor. If the trusted anchor option does not match any certificate, the AR returns the Trusted Anchor sub-options in the reply. The MN SHOULD immediately conduct a Certificate Revocation List (CRL) check on any certificates obtained through CARD certificate exchange, to make sure that the certificates are still valid.
IPv4では、証明書を取得するためのDCS / DCAメッセージはありません。 MNは、ARのための証明書を持っていない場合、MNが持っている各共有信頼アンカーのために、MNは、その現在のAPのL2 IDを含むCARD要求メッセージを送信し、一の信頼できるアンカーサブオプション（セクション5.1.3.6）証明書は、現在のARのための証明書パスを取得します。信頼アンカーサブオプションのコンポーネントのフィールドは、全体の証明書パスが必要とされていることを示すために65535に設定されています。他のオプションは、リクエストに含まれるべきではありません。 ARは一致し、その証明書パス内の1つの証明書を含む要求で送信さL2 IDサブオプションを含むCARD応答、自体のアドレスサブオプション、およびルータ証明書サブオプション（セクション5.1.3.7）を送信することによって応答しますコンテキスト-IDと一致するすべてのサブオプションの設定要求されたトラストアンカー、および無他のサブオプションのいずれか、。すべてのコンポーネントフィールドは、パスの長さに設定され、コンポーネントフィールドは、経路中のこの成分の数に設定されています。パスはつの証明書よりも長い場合、ARは、同じコンテキストで、起因するICMPメッセージの長さの制限に、L2 IDサブオプションと最初の証明書のアドレスサブオプションと別個ICMPメッセージ内の他の証明書を送信します。 -ID各ルート証明書のサブオプションを設定して、コンポーネントのフィールドで適切に設定してください。ルータは、信頼できるアンカーの証明書を送信すべきではなく、信頼できるアンカーの後に証明書から順番に証明書を送るべきです。信頼されたアンカーオプションは、すべての証明書と一致しない場合は、ARは、回答に信頼アンカーサブオプションを返します。 MNはすぐに証明書がまだ有効であることを確認するために、カード証明書交換を経て得られたすべての証明書の証明書失効リスト（CRL）のチェックを実施すべきです。
Certification paths for CARs may be fetched in advance of handover by requesting them as part of the CARD protocol. In that case, the MN includes Trusted Anchor sub-options in the CARD request along with the L2 ID sub-option for the AP for which the CAR certificate is desired, and the AR replies as above, except that the L2 ID, address, and certificates are for the CAR instead of for the AR itself. This allows the MN to skip the DCS/DCA or CARD certificate exchange when it moves to a new router.
車のための証明書パスは、CARDプロトコルの一部としてそれらを要求することによって、ハンドオーバの前にフェッチすることができます。その場合、MNは、CAR証明書が望まれているAPのためのL2 IDサブオプションと共にCARD要求にアンカーサブオプションを信頼含み、ARは、L2 ID、アドレスことを除いて、上記のように返信そして、証明書は、CARのための代わりに、AR自体のためのものです。これは、新しいルータに移動するときにMNがDCS / DCAまたはカード証明書交換をスキップすることができます。
Because the amount of space in an ICMP message is limited, the router certification paths SHOULD be kept short.
ICMPメッセージ内のスペースの量は限られているため、ルータの証明書パスが短く保たれるべきです。
An AR can be overwhelmed with CARD Request messages. The AR SHOULD implement a rate-limiting policy so that it does not send or process more than a certain number of messages per period. The following is a suggested rate limiting policy. If the number of CARD messages exceeds CARD_REQUEST_RATE, the AR SHOULD begin to drop messages randomly until the rate is reduced. MNs SHOULD avoid sending messages more frequently than CARD_REQUEST_RATE. ARs SHOULD also avoid sending unsolicited CARD Replies or CARD Requests more frequently than CARD_MIN_UPDATE_INTERVAL, but, in this case, the existence of an IPsec security association ensures that messages from unknown entities will be discarded immediately during IPsec processing.
ARはCARD Requestメッセージで圧倒することができます。それが送信または期間ごとのメッセージの一定数以上を処理しないように、ARは、レート制限ポリシーを実装する必要があります。以下は、提案レート制限ポリシーです。 CARDメッセージの数がCARD_REQUEST_RATEを超えた場合、ARは率が低下するまで、ランダムにメッセージをドロップを開始する必要があります。 MNがCARD_REQUEST_RATEよりも頻繁にメッセージを送信することは避けてください。 ARもCARD_MIN_UPDATE_INTERVALよりも頻繁に迷惑CARDの回答やカードの要求を送信することは避けてください、しかし、この場合には、IPsecセキュリティ協会の存在は、未知のエンティティからのメッセージは、IPsec処理中にすぐに破棄されることを保証します。
MNs MUST discard CARD Replies for which there is no outstanding CARD Request, as indicated by the sequence number.
シーケンス番号によって示されるように、未処理のCARD要求がないいるのMNは、CARD応答を捨てなければなりません。
To protect against replay attacks on the AR-AR interface, ARs SHOULD enable replay protection when negotiating the IPsec security association using IKE.
IKEを使用したIPsecセキュリティアソシエーションをネゴシエートするときにAR-ARインタフェース上のリプレイ攻撃から保護するため、ARSが再生保護を有効にする必要があります。
On the MN-AR interface, the MN MUST discard any CARD Replies for which there is no outstanding request, as determined by the sequence number. For ARs, an attacker can replay a previous request from an MN, but the attack is without serious consequence because the MN ignores the reply in any case.
MN-ARインタフェースに、MNは、シーケンス番号によって決定されるように、未処理の要求がないいる任意のCARD応答を捨てなければなりません。 ARの場合、攻撃者は、MNからの前の要求を再生することができますが、MNが、いずれにしても返事を無視するので、攻撃は深刻な結果なしです。
Constant Section Default Value Meaning
--------------------------------------------------------------------
CARD_REQUEST_RETRY 5.1.1 2 seconds Wait interval before
initial retransmit
on MN-AR interface.
CARD_RETRY_MAX 5.1.1 15 seconds Give up on retry on MN-AR interface.
CARD_RETRY_MAX 5.1.1 15秒は、MN-ARインタフェース上で再試行を諦めます。
CARD_STARTUP_WAIT 5.2.1 1-3 seconds Maximum startup wait for an AR before performing AR-AR CARD.
AR-ARカードを実行する前に、ARのためのCARD_STARTUP_WAIT 5.2.1 1-3秒最大スタートアップ待ち時間。
CARD_MIN_UPDATE_INTERVAL 5.2.1 60 seconds Minimum AR-AR update interval.
CARD_MIN_UPDATE_INTERVAL 5.2.1 60秒最小AR-ARの更新間隔。
CARD_REQUEST_RATE 6.5 2 requests/ Maximum number of sec. messages before AR institutes rate limiting.
CARD_REQUEST_RATE 6.5 2リクエスト/秒の最大数。 AR機関のレート制限の前にメッセージを。
See [Ke04] for instructions on IANA allocation.
IANAの割り当て方法については、[KE04]を参照してください。
[Brad97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Brad97]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[Stew00] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
【Stew00]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[AtKe98] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[AtKe98]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[HarCar98] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[HarCar98]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[Arkko04] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
【Arkko04] Arkko、J.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[Ke04] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[KE04]ケンプ、J.、RFC 4065、2005年7月 "Seamobyと実験モビリティプロトコルのIANAの割り当てのための手順"。
[TKCK02] Trossen, D., Krishanmurthi, G. Chaskar, H., Kempf, J., "Issues in candidate access router discovery for seamless IP-level handoffs", Work in Progress.
[TKCK02] Trossen、D.、Krishanmurthi、G. Chaskar、H.、ケンプ、J.、 "シームレスなIPレベルでのハンドオフのための候補アクセスルータ発見における問題" が進行中で働いています。
[MaKo03] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[MaKo03]マナー、J.とM.古城、 "モビリティ関連用語"、RFC 3753、2004年6月。
[Kood03] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[Kood03] Koodli、R.、エド。、 "モバイルIPv6のための高速ハンドオーバ"、RFC 4068、2005年7月。
[Funa02] Funato, D., et al., "Geographically Adjacent Access Router Discovery Protocol", Work in Progress.
【Funa02]船戸、D.、ら、「地理的隣接アクセスルータ発見プロトコル」、ProgressのWork。
[Tros03] Trossen, D., et al., "A Dynamic Protocol for Candidate Access-Router Discovery", Work in Progress.
【Tros03] Trossen、D.、ら、「候補アクセス・ルータ発見のための動的プロトコル」、ProgressのWork。
[ShGi00] Shim, E. and R. Gitlin, "Fast Handoff Using Neighbor Information", Work in Progress.
[ShGi00]シム、E.およびR. Gitlin、「ネイバー情報を用いた高速ハンドオフ」が進行中で働いています。
[Malk03] El Malki, K., et al., "Low Latency Handoffs in Mobile IPv4", Work in Progress.
【Malk03]エルMalki、K.、ら。、「モバイルIPv4における低遅延ハンドオフ」、進行中の作業。
The authors would like to thank Vijay Devarapalli (Nokia) and Henrik Petander (Helsinki University of Technology) for formally reviewing the protocol specification document and providing valuable comments and input for technical discussions. The authors would also like to thank James Kempf for reviewing and for providing a lot of valuable comments and editing help.
著者は、正式プロトコル仕様書をレビューし、技術的な議論のための貴重なコメントや入力を提供するためのビジェイDevarapalli（ノキア）とヘンリクPetander（ヘルシンキ工科大学を）感謝したいと思います。著者らはまた、見直しのために、貴重なコメントや編集の多くの援助を提供するためのジェームズ・ケンプに感謝したいと思います。
The authors would like to thank (in alphabetical order) Dirk Trossen, Govind Krishnamurthi, James Kempf, Madjid Nakhjiri, Pete McCann, Rajeev Koodli, Robert C. Chalmers, and other members of the Seamoby WG for their valuable comments on the previous versions of the document, as well as for the general CARD-related discussion and feedback. In addition, the authors would like to thank Erik Nordmark for providing valuable insight about the piggybacking of CARD options upon Fast Mobile IPv6 messages.
著者は、以前のバージョンの彼らの貴重なコメントのために（アルファベット順）ディルク・Trossen、Govind Krishnamurthi、ジェームズ・ケンプ、マジドNakhjiri、ピートマッキャン、ラジーブKoodli、ロバート・C・チャルマーズ、およびSeamoby WGの他のメンバーに感謝したいと思います文書だけでなく、一般的なカード関連の議論とフィードバックのために。また、著者は、高速モバイルIPv6メッセージ時にカードオプションのピギーバックについての貴重な洞察を提供するためのエリックNordmarkとに感謝したいと思います。
Appendix A. Maintenance of Address Mapping Tables in Access Routers
アクセスルータのアドレスマッピングテーブルの付録A.メンテナンス
This appendix provides information on two optional CAR table maintenance schemes for reverse address mapping in access routers. These schemes replace static configuration of the AP L2 ID-to-CAR IP address mapping in the CAR table. Details on these mechanisms are out of the scope of this document. The intention of this appendix is to provide only a basic idea on flexible extensions to the CARD protocol, as described in this document.
この付録では、アクセスルータにリバースアドレスマッピングのための2つのオプションのCARテーブルのメンテナンススキームに関する情報を提供します。これらのスキームは、CARテーブル内のAP L2 IDツーCAR IPアドレスマッピングの静的な構成を交換してください。これらのメカニズムの詳細については、この文書の範囲外です。この付録の意図は、この文書で説明するように、CARDプロトコルへの柔軟な拡張にのみ基本的なアイデアを提供することです。
Appendix A.1. Centralized Approach Using a Server Functional Entity
付録A.1。サーバーの機能エンティティを使用して一元的アプローチ
The centralized approach performs CARD over the MN-AR interface as described in Section 4 of this document. Additionally, the centralized approach introduces a new entity, the CARD server, to assist the current AR in performing reverse address translation. The centralized approach requires that neighboring ARs register with the CARD server to populate the reverse address translation table. The registration of AR addresses with the CARD server is performed prior to initiation of any reverse address translation request.
このドキュメントのセクション4で説明したように、集中型のアプローチは、MN-ARインタフェースを介してカードを行います。また、集中型のアプローチは逆のアドレス変換を実行する際に、現在のARを支援する新しいエンティティ、CARDサーバが導入されています。集中型のアプローチは、隣接のARが逆のアドレス変換テーブルを移入するCARDサーバに登録する必要があります。 CARDサーバとARアドレスの登録は任意の前に、逆アドレス変換要求の開始に行われます。
Figure A.1 illustrates a typical scenario of the centralized CARD operation. In this example, ARs have registered their address information with a CARD server in advance. When an MN discovers the L2 ID of APs during L2 scanning, it passes one or more L2 IDs to its current AR, and the AR resolves them to the IP address of the AR. For this, the AR first checks whether the mapping information is locally available in its CAR table. If it is not, the MN's current AR queries a CARD server with the L2 ID. In response, the CARD server returns the IP address of the CAR to the current AR. Then, the current AR directly contacts the respective CAR and performs capability discovery with it. The current AR then passes the IP address of the CAR and associated capabilities to the MN. The current AR then stores the resolved IP address within its local CAR table. The centralized CARD protocol operation introduces additional signaling messages, which are exchanged between the MN's current AR and the CARD server. The signaling messages between an AR and the CARD server function are shown with the preceding identifier "AR-Server", referring to the associated interface.
図A.1は、集中カード操作の典型的なシナリオを示します。この例では、ARSが事前にカードサーバとのアドレス情報を登録しています。 MNは、L2の走査中のAPのL2 IDを検出すると、それは現在のARへの1つ以上のL2 IDを渡し、ARは、ARのIPアドレスにそれらを解決します。このため、マッピング情報は、そのCARテーブルにローカルに利用可能であるかどうかを最初にチェックAR。そうでない場合は、MNの現在のARはL2 IDとカードサーバを照会します。それに応答して、カードサーバは、現在のARにCARのIPアドレスを返します。その後、現在のAR直接接触それぞれCARおよびそれに能力の発見を行います。現在のARは、MNにCARと関連する機能のIPアドレスを渡します。現在のARは、その地域のCARテーブル内で解決したIPアドレスを格納します。集中型のCARDプロトコルの動作は、MNの現在のARとCARDサーバ間で交換される追加のシグナリングメッセージを、紹介します。 ARとCARDサーバ機能との間のシグナリングメッセージは、関連付けられたインターフェイスを参照して、前述の識別子「AR-サーバ」で示されています。
An initial idea of performing reverse address translation using a centralized server is described in [Funa02].
中央サーバを使用して、逆アドレス変換を実行する最初のアイデアは、[Funa02]に記載されています。
+----------+
+------------>| CARD |<-------------+
|+------------| Server |-------------+|
|| +----------+ ||
|| ||
|| ~~~~~~~~~~~ ||
(3)AR-Server||(4)AR-Server{ } ||(0) CARD
CARD || CARD { } ||Reg Req/
Request || Reply { IP Cloud } | Reply
|| { } ||
|| { } ||
|V ~~~~~~~~~~~ V|
+---------+ (5)AR-AR CARD Request +-----+-----+
| Current |------------------------->| CAR | CAR |
| AR |<-------------------------| 1 | 2 |
+---------+ (6)AR-AR CARD Reply +-----+-----+
^ | | |
(2)MN-AR | |(7)MN-AR | |
CARD | | CARD | |
Request| V Reply +---+ +---+
+--------------+ (1) AP1 L2 ID +--|AP1| |AP2|
| Mobile |<---------------------+ +---+ +---+
| Node |<--------------------------------+
+--------------+ (1) AP2 L2 ID
Figure A.1: Centralized Approach for L2-L3 Mapping
図A.1：L2-L3マッピングのための集中型アプローチ
Appendix A.2. Decentralized Approach Using Mobile Terminals' Handover
付録A.2。モバイル端末のハンドオーバーを使用して分散型のアプローチ
This approach performs CARD over the MN-AR interface as described in Section 4. However, it employs one additional message, called the Router Identity message, over the MN-AR interface to enable ARs to learn about the reverse address translation tables of their neighboring ARs, without being dependent on any centralized server.
第4節で説明したように、このアプローチは、しかし、それは一つの追加メッセージを採用し、その隣の逆アドレス変換テーブルについて学ぶためのARを可能にするために、MN-ARインタフェース上で、ルータIdentityメッセージと呼ばれるMN-ARインタフェースを介してカードを行い、 AR、任意の中央サーバに依存せず。
In this approach, CAR identities in the CAR table of an AR are maintained as soft state. The entries for CARs are removed from the CAR table if they are not refreshed before the timeout period expires and are created or refreshed according to the following mechanism.
このアプローチでは、ARのCARテーブルのCARアイデンティティはソフト状態として維持されます。それらはタイムアウト期間が満了する前にリフレッシュされないと、次のようなメカニズムに基づいて作成または更新された場合に車のためのエントリは、CARテーブルから削除されます。
The key idea behind the decentralized approach is to bootstrap and maintain the association between two ARs as neighbors of each other using the actual handover of MNs occurring between them as input. The first handover between any two neighboring ARs serves as the bootstrap handover to invoke the discovery procedure, and the subsequent handover serves to refresh the association between the neighboring ARs. After the bootstrap handover, the MNs can perform
分散型アプローチの背後にある主要なアイデアは、ブートストラップ入力としてそれらの間に発生するMNの実際のハンドオーバを用いて互いの近隣のような2つのARの間の関連を維持することです。任意の二つの隣接アクセスルータとの間の最初のハンドオーバが発見手順を呼び出すために、ブートストラップハンドオーバーとなり、その後のハンドオーバーは、隣接アクセスルータとの間の関連付けを更新するのに役立ちます。ブートストラップ、ハンドオーバー後、MNが行うことができます
CARD and thus seamless handover using the CAR information. This idea was presented in [ShGi00] and [Tros03].
CAR情報を使用してカードので、シームレスなハンドオーバー。このアイデアは、[Tros03] [ShGi00]に提示させました。
Maintenance of the CAR table is done by using an additional option for the CARD protocol operation performed between an MN and its current AR. This message serves as Router Identity message.
CARテーブルのメンテナンスは、MNとその現在のARとの間で行われるCARDプロトコル操作のための追加オプションを使用して行われます。このメッセージは、ルータIdentityメッセージとして機能します。
Upon the completion of an inter-AR handover, the MN SHOULD send a Router Identity message to its current AR. This message contains the identity (IP address) of the previous AR (pAR), and can be sent as a specific sub-option in the MN-AR CARD Request message. It SHOULD be acknowledged with the MN-AR CARD Reply. The Router Identity message enables the MN's current AR to learn that the pAR (still) has an AP whose coverage overlaps with one of the APs of the current AR, and vice versa. With this information, the MN's current AR can create or refresh an entry for the pAR as its neighbor. If handover is no longer possible between two ARs, the associated entries eventually timeout and are removed from each AR's CAR table.
インターARハンドオーバが完了すると、MNは、その現在のARへのルータIdentityメッセージを送信すべきです。このメッセージは、前のAR（PAR）のアイデンティティ（IPアドレス）を含み、MN-AR CARD Requestメッセージで特定のサブオプションとして送信することができます。これは、MN-ARカード返信して承認されるべきです。ルータのアイデンティティメッセージは、PARを（まだ）そのカバレッジその逆電流ARのAPのいずれかに重なるAPを持っていることを学ぶためにMNの現在のARを可能にします。この情報によって、MNの現在のARは、その隣人としてのARのためのエントリを作成または更新することができます。ハンドオーバが2つのARの間ではもはや不可能である場合は、関連するエントリは最終的にタイムアウトし、各ARのCARテーブルから削除されます。
Prior to trusting the MN's report, however, the current AR may perform a number of checks to ensure the validity of the received information. One simple method is to verify the accuracy of the Router Identity message by sending an AR-AR CARD Request message to the pAR. The AR-AR CARD Request includes the identity of the MN. Upon receiving this message, the pAR verifies that the MN was indeed attached to it during a reasonable past interval and responds to the current AR. In this way, each handover of a MN results in a bi-directional discovery process between the two participating ARs.
MNの報告書を信頼する前に、しかし、現在のARは、受信した情報の有効性を確認するためにいくつかのチェックを行うことができます。一つの簡単な方法は、パラメーターにAR-AR CARD要求メッセージを送信することによって、ルータのアイデンティティメッセージの正確さを検証することです。 AR-ARカード要求は、MNのアイデンティティを含んでいます。このメッセージを受信すると、PARがMNは確かに合理的な過去の期間中に、それに接続されたことを確認し、現在のARに応答します。このように、MNの各ハンドオーバは、二つの参加のAR間の双方向検出プロセスをもたらします。
Upon receiving a positive verification response, the current AR creates or refreshes, as applicable, the entry for the pAR in its local CAR table. In the former case, the current AR and the pAR exchange capabilities using the AR-AR CARD Request and AR-AR CARD Reply protocol messages. When a new entry is created, the ARs MUST exchange their reverse address translation tables. They may exchange other capabilities at this time or may defer exchange to a later time when some MN undergoing handover between them performs CARD as described in Section 4. In the latter (refresh) case, ARs may exchange capabilities or defer exchanges until a later time when another MN undergoes handover.
肯定確認応答を受信すると、現在のARは、必要に応じて、そのローカルCARテーブルにおけるPARのためのエントリを作成またはリフレッシュ。 AR-ARのCARD要求とAR-ARのCARD応答プロトコルメッセージを使用して、前者の場合には、現在のARおよびPAR交換機能。新しいエントリが作成されると、ARSがその逆のアドレス変換テーブルを交換しなければなりません。彼らは、この時点で他の機能を交換することができるか、後の時点まで後者（リフレッシュ）の場合、セクション4で説明したように、それらの間のハンドオーバを受け、いくつかのMNがカードを行う場合、アクセスルータは、機能を交換または交換を延期することができる後の時点に交換を延期することができますとき、他のMNがハンドオーバを受けます。
Finally, note that in a handover-based protocol, a first handover between a pAR and an MN's current AR cannot use CARD, as this handover bootstraps the CAR table. However, in the long term, such a handover will only amount to a small fraction of total successful handover between the two ARs. Also, if the MN engaging in such a first handover is running a non-delay sensitive application at the time of handover, the user may not even realize its impact.
最後に、ハンドオーバ・ベースのプロトコルでパーとMNの現在のARとの間の最初のハンドオーバがこのハンドオーバブートストラップCARテーブルとして、カードを使用できないことに注意。しかし、長期的に、そのようなハンドオーバは2つのだけのAR間の全成功のハンドオーバの小さな画分に達するだろう。そのような最初のハンドオーバに係合MNは、ハンドオーバ時に非遅延に敏感なアプリケーションを実行している場合も、ユーザは、さらに、その衝撃を実現しないかもしれ。
Appendix B. Application Scenarios
付録B.アプリケーションシナリオ
This section provides two examples of application scenarios for CARD protocol operation. One scenario describes a CARD protocol operation in a Mobile IPv6 (MIPv6) network, providing access to the infrastructure via wireless LAN Access Points and associated Access Routers. A second scenario describes CARD protocol operation in a Mobile IPv6-enabled network, which has enhanced support for fast handover integrated (Fast Mobile IPv6), also providing wireless LAN access to the infrastructure.
このセクションでは、CARDプロトコル操作のためのアプリケーションシナリオの2つの例を提供します。一つのシナリオでは、無線LANアクセスポイントと関連するアクセスルータを介してインフラストラクチャへのアクセスを提供する、モバイルIPv6（MIPv6の）ネットワーク内のCARDプロトコルの動作を説明します。第2のシナリオはまた、インフラストラクチャへの無線LANアクセスを提供する、集積高速ハンドオーバ（高速モバイルIPv6）のサポートを強化したモバイルIPv6対応ネットワークにCARDプロトコル動作について説明します。
This application scenario assumes a moving MN having access to the infrastructure through wireless LAN (IEEE802.11) APs. Mobility management is performed using the Mobile IPv6 protocol. The following figure illustrates the assumed access network design.
このアプリケーションシナリオは、無線LAN（IEEE802.11）のAPを介してインフラストラクチャへのアクセスを有する移動MNを想定しています。モビリティ管理は、モバイルIPv6プロトコルを使用して実行されます。次の図は、想定アクセスネットワーク設計を示しています。
Appendix B.1. CARD Operation in a Mobile IPv6-Enabled Wireless LAN Network
付録B.1。モバイルIPv6対応の無線LANネットワークにおけるカード操作
-----------------------------
/ \ +----+
| NETWORK |---| HA |
\ / +----+
-----------------------------
| |
+-----+ +-----+
| AR1 |---------+ | AR2 |
+-----+ | +-----+
| subnet 1 | |subnet 2
+-----+ +-----+ +-----+
| AP1 | | AP2 | | AP3 |
+-----+ +-----+ +-----+
^ ^ ^
\
\
\
v
+-----+
| MN | - - ->>>- - - ->>>
+-----+
Figure B.1: Assumed Network Topology
図B.1：想定するネットワークトポロジ
A Mobile IPv6 Home Agent (HA) maintains location information for the MN in its binding cache. In Figure B.1, the MN holds a care-of address for the subnet 1, supported by AR1. As the MN moves, the MN's current environment offers two further wireless LAN APs with increasing link-quality as candidate APs for a handover. To facilitate decision making, parameters associated with ARs are taken into account during the decision process. The AR-related parameters can be, for example, available QoS resources or the type of access technologies supported from an AR. To learn about these candidate ARs' capabilities and associated IP address information, the MN performs CARD. This requires retrieving information about candidate APs' L2 IDs. Furthermore, associated link-quality parameters are retrieved to ascertain whether approaching APs are eligible candidates for a handover. If AP2 and AP3 are suitable candidate APs, the MN encapsulates both L2 IDs (AP2 and AP3) into a CARD Request message, using the L2 ID sub-option, and sends the message to its current AR (AR1).
モバイルIPv6ホームエージェント（HA）は、その結合キャッシュにMNの位置情報を保持します。図B.1では、MNは、気付アドレス、サブネット1のため、AR1によってサポートさを保持しています。 MNが移動すると、MNの現在の環境では、ハンドオーバの候補APとしてリンク品質の増加に伴って、さらに2つの無線LANのアクセスポイントを提供しています。意思決定を容易にするために、のARに関連するパラメータは、意思決定プロセスの中に考慮されています。 AR関連のパラメータは、例えば、利用可能なQoSリソース又はARから支持アクセス技術の種類であってもよいです。これらの候補のARの能力と関連したIPアドレス情報の詳細については、MNがCARDを実行します。これは、候補APのL2 IDに関する情報を取得する必要があります。さらに、関連するリンク品質のパラメータが近づいAPがハンドオーバの対象候補であるかどうかを確認するために取得されています。 AP2及びAP3は、適切な候補APがある場合、MNは、L2 IDサブオプションを使用して、CARD要求メッセージにL2 IDを（AP2及びAP3）の両方をカプセル化し、その現在のAR（AR1）にメッセージを送信します。
AR1 resolves each L2 ID listed in L2 ID options to the associated IP address of the respective CAR, making use of its local CAR table. According to the environment illustrated in Figure B.1, the associated AR IP address of the candidate AP2 will be the same as the MN is currently attached to, which is AR1. The corresponding IP address of the candidate AR, to which AP3 is connected, is the address of AR2. IP addresses of the MN's CARs are now known to AR1, which retrieves the CARs' capabilities from the CAR table. Assuming that it has valid entries for respective capability parameters to refresh dynamic capabilities, whose associated lifetimes in AR1's CAR table have expired, AR1 performs Inter-AR CARD for capability discovery. Since capability information for AR1 is known to AR1, a respective Inter-AR CARD Request is sent only to AR2. In response, AR2 sends a CARD Reply message back to AR1, encapsulating the requested capability parameters with the signaling message in a Capability Container sub-option.
AR1は、そのローカルCARテーブルを利用して、それぞれのCARの関連したIPアドレスへのL2 IDオプションでリストされた各L2 IDを解決します。図B.1に示されている環境に応じて、候補の関連するARのIPアドレスは、AP2はAR1である現在に取り付けられているMN、と同じになります。候補ARの対応するIPアドレス、AP3が接続されている、AR2のアドレスです。 MNの自動車のIPアドレスは、現在CARテーブルから車の能力を取得AR1に知られています。それはその関連する寿命AR1のCARテーブル内の有効期限が切れている動的機能を、リフレッシュするために、それぞれの能力パラメータの有効なエントリを持っていると仮定すると、AR1は、能力発見のためのInter-ARカードを実行します。 AR1のための能力情報は、AR1に知られているので、それぞれの間ARカード要求だけAR2に送信されます。これに応答して、AR2は、能力コンテナサブオプション内のシグナリングメッセージで要求された機能パラメータをカプセル化する、バックAR1にCARD応答メッセージを送信します。
Next, AR1 sends its own capabilities and the dynamically discovered ones of AR2 back to the MN via a CARD Reply message. Furthermore, AR1 stores the capability parameters of AR2 with the associated lifetimes in its local CAR table.
次に、AR1はCARD Replyメッセージを経由して戻ってMNへの独自の機能とAR2の動的に発見されたものを送信します。さらに、AR1はそのローカルCARテーブル内の関連する寿命とAR2の能力パラメータを記憶します。
Upon receipt of the CARD Reply message, the MN performs target AR selection, taking AR1's and AR2's capability parameters and associated APs' link-quality parameters into account. If the selected AP is AP2, no IP handover needs to be performed. If AP3 and the associated AR2 are selected, the MN needs to perform an IP handover according to the Mobile IPv6 protocol operation.
CARD Replyメッセージを受信すると、MNは考慮AR1さんとAR2の能力パラメータと関連するAPのリンク品質パラメータを取って、ターゲットARの選択を行います。選択したAPがAP2である場合は、IPハンドオーバが実行される必要がありません。 AP3と関連AR2が選択されている場合、MNは、モバイルIPv6プロトコルの動作に応じてIPハンドオーバを実行する必要があります。
Figure B.2 illustrates the signaling flow of the previously described application scenario of CARD within a Mobile IPv6-enabled network.
図B.2は、モバイルIPv6対応のネットワーク内のCARDの前述のアプリケーションシナリオのシグナリング・フローを示します。
MN AP1 AR1 AP2 AP3 AR2
| | | | | |
| connected | | | | |
0-------------0-------0 | | |
| | | | | |
| | | | | |
| | | |
| <~~~~~~~~~L2-SCAN (AP2)~~~~~| | |
| <~~~~~~~~~L2-SCAN (AP3)~~~~~~~~~~~~~~~~~| |
| | | |
| (MN-AR) CARD Req | | | |
|-------------------->| (AR-AR) CARD Req |
| | |---------------------------------------->|
| | | (AR-AR) CARD Repl |
| (MN-AR) CARD Repl |<----------------------------------------|
|<--------------------| | | |
| | | | | |
[target AR | | | | |
selection] | | | | |
| | | | | |
// // // // // //
[either...] | | | | |
| | | | | |
|-------- L2 attach --------->| | |
| | | | | |
| connected | | | |
0---------------------0-------0 | |
| | | | | |
// // // // // //
[... or] | | | | |
| | | | | |
|--------------- L2 attach -------------->| |
| | | | | |
| connected | | | |
0-----------------------------------------0---------------------0
| | | | | |
| | |
| MIPv6 Binding Update to the HA | |
|------------------------------------------------ - - - > |
| | | | | |
Figure B.2. CARD Protocol Operation within a Mobile IPv6-Enabled Wireless LAN Network
図B.2。モバイルIPv6対応の無線LANネットワーク内のCARDプロトコル動作
Appendix B.2. CARD Operation in a Fast Mobile IPv6 Network
付録B.2。高速モバイルIPv6ネットワークにおけるカード操作
This application scenario assumes that ARs can perform the fast handover protocol sequence for Mobile IPv6 [Kood03]. The MN scans for new APs for handover, similar to Figure B.1. To discover the ARs (CARs), the MN attaches a MN-AR CARD Request option to the ICMP-type Fast Mobile IPv6 RtSolPr message, which is sent to the MN's current AR (pAR, previous AR).
このアプリケーションシナリオは、アクセスルータは、モバイルIPv6 [Kood03]の高速ハンドオーバプロトコルシーケンスを実行することができることを前提としています。図B.1と類似のハンドオーバのための新たなAPの、のためのMNをスキャンします。 AR（車）を発見するために、MNは、MNの現在のAR（PAR、前のAR）に送信されるICMP型高速モバイルIPv6 RtSolPrをメッセージにMN-AR CARD要求オプションを付加します。
Candidate APs' L2 IDs are encapsulated using the CARD protocol's L2 ID sub-options, which allow the MN to send multiple L2 IDs of candidate APs to its current AR. (This potentially replaces the "New Attachment Point Link-Layer Address" option of the Fast Mobile IPv6 protocol.)
候補APのL2 IDは、MNが現在のARに候補APの複数L2 IDを送信することを可能にするCARDプロトコルのL2 IDサブオプションを使用してカプセル化されます。 （これは潜在的に「新しいアタッチメントポイントリンク層アドレス」高速モバイルIPv6プロトコルのオプションを置き換えます。）
The pAR resolves the received list of candidate APs' L2 IDs to the IP addresses of associated CARs. The pAR checks its local CAR table to retrieve information about the CARs' capabilities. If any table entries have expired, the pAR acquires this CAR's capabilities by sending an AR-AR CARD Request to the respective CAR. The CAR replies with an AR-AR CARD Reply message, encapsulating all capabilities in a Capability Container sub-option and attaching them to the CARD Reply option. On receipt of the CARs' capability information, the pAR updates its local CAR table and forwards the address and capability information to the MN by attaching a MN-AR CARD Reply option to the Fast Mobile IPv6 PrRtAdv message. When the MN's handover is imminent, the MN selects its new AR and the associated new AP from the discovered list of CARs. According to the Fast Mobile IPv6 protocol, the MN notifies the pAR of the selected new AR with the Fast Binding Update (F-BU) message, allowing the pAR to perform a fast handover according to the Fast Mobile IPv6 protocol.
PARが関連する自動車のIPアドレスに候補APのL2 IDの受信リストを解決します。 PARが車の機能に関する情報を取得するために、そのローカルCARテーブルをチェック。任意のテーブルのエントリが期限切れになった場合は、PARがそれぞれのCARにAR-ARカード要求を送信することによって、このCARの能力を獲得します。 CARは、能力コンテナサブオプションですべての機能をカプセル化し、カードの返信オプションに添付、AR-AR CARD Replyメッセージで応答します。車の能力情報を受信すると、PARがそのローカルCARテーブルを更新し、高速モバイルIPv6代理ルータ広告メッセージにMN-AR CARD返信オプションを取り付けることによって、MNへのアドレスと能力情報を転送します。 MNのハンドオーバが差し迫っている場合には、MNは、その新しいARや車の発見リストから関連する新しいAPを選択します。高速モバイルIPv6プロトコルによれば、MNがPARを高速モバイルIPv6プロトコルに従った高速ハンドオーバを実行することができ、高速バインディングアップデート（F-BU）メッセージで選択された新しいARの額面を通知します。
Optionally, the pAR could perform selection of an appropriate new AR on behalf of the MN after the pAR has the MN's CARs' addresses and associated capabilities available. The MN must send its requirements for the selection process to its pAR together with the MN-AR CARD Request message After the pAR has selected the MN's new AR, the address and associated capabilities of the chosen new AR are sent to the MN with the CARD Reply option in the Fast Mobile IPv6 PrRtAdv message.
PARをMNの車のアドレスと利用可能な関連する機能を持っていた後、必要に応じて、PARがMNに代わって適切な新しいARの選択を行うことができます。 PARをCARDでMNに送信されたMNの新しいAR、住所、選択した新しいARの関連する機能を選択した後、MNは、MN-AR CARD Requestメッセージと一緒にそのPAR発選択プロセスのためにその要件を送信する必要があります高速モバイルIPv6代理ルータ広告メッセージにオプションを返信します。
Figure B.3 illustrates how CARD protocol messages and functions work with the Fast Mobile IPv6 protocol.
図B.3はCARDプロトコルメッセージや機能が高速モバイルIPv6プロトコルで動作する方法を示します。
MN pAR NAR CAR2
| | as CAR1 |
| | | |
|-------RtSolPr------>| | |
| [MN-AR CARD Req] |-- AR-AR CARD Req*->| |
| |-- AR-AR CARD Req*------------>|
| |<--AR-AR CARD Repl*------------|
| |<--AR-AR CARD Repl*-| |
|<------PrRtAdv-------| | |
| [MN-AR CARD Repl] | | |
| | | |
NAR selection | | |
|------F-BU---------->|--------HI--------->| |
| |<------HACK---------| |
| <--F-BACK--|--F-BACK--> | |
| | | |
Disconnect | | |
| forward | |
| packets===============>| |
| | | |
| | | |
Connect | | |
| | | |
RS (with FNA option)======================>| |
|<-----------RA (with NAACK option)--------| |
|<=================================== deliver packets |
| | |
Figure B.3. Fast Handover Protocol Sequence with
CARD Protocol Options
* In Figure B.3, the CARD protocol interaction between the pAR and CARs is only required if the lifetime of any capability entries in the pAR's CAR table have expired. Otherwise, the pAR can respond to the requesting MN immediately after retrieving the CARs' addresses and capability information from its CAR table.
ARのCARテーブル内のすべての機能エントリの寿命が期限切れになった場合*図B.3でパーと車両間CARDプロトコルの相互作用にのみ必要です。そうしないと、PARがすぐにそのCARテーブルから車のアドレスと能力情報を取得した後、要求MNに対応することができます。
Authors' Addresses
著者のアドレス
Hemant Chaskar AirTight Networks 339 N. Bernardo Avenue Mountain View, CA 94043, USA
Hemant Chaskar気密ネットワーク339 N.ベルナルド・アベニューマウンテンビュー、CA 94043、USA
EMail: hemant.chaskar@airtightnetworks.net
メールアドレス：hemant.chaskar@airtightnetworks.net
Daichi Funato NTT DoCoMo, Inc. Communication Systems Laboratory Wireless Laboratories 3-5, Hikarinooka, Yokosuka, Kanagawa 239-8536, Japan
だいち ふなと んっｔ どこも、 いんｃ。 こっむにかちおん Ｓｙｓてｍｓ ぁぼらとｒｙ うぃれぇっｓ ぁぼらとりえｓ ３ー５、 ひかりのおか、 よこすか、 かながわ ２３９ー８５３６、 じゃぱん
Phone: +81-46-840-3921 EMail: funato@mlab.yrp.nttdocomo.co.jp
電話：+ 81-46-840-3921 Eメール：funato@mlab.yrp.nttdocomo.co.jp
Marco Liebsch NEC Network Laboratories Kurfuersten-Anlage 36, 69115 Heidelberg, Germany
マルコLiebsch NECネットワーク研究所Kurfuersten-Anlageの36、ハイデルベルク、ドイツ
Phone: +49 6221-90511-46 EMail: marco.liebsch@netlab.nec.de
電話：+49 6221-90511-46 Eメール：marco.liebsch@netlab.nec.de
Eunsoo Shim Panasonic Digital Networking Laboratory Panasonic Corporation Two Research Way Princeton, NJ 08540
Eunsooシムパナソニックのデジタル・ネットワーキング研究所パナソニック株式会社二つの研究ウェイプリンストン、NJ 08540
Phone: +1-609-734-7354 EMail: eunsoo@research.panasonic.com
電話：+ 1-609-734-7354 Eメール：eunsoo@research.panasonic.com
Ajoy Singh Motorola Inc 2G11, 1501 West Shure Dr. Arlington Heights, IL 60004, USA
Ajoyシンモトローラ社2G11、1501年西Shureの博士アーリントンハイツ、IL 60004、USA
Phone: +1 847-632-6941 EMail: asingh1@email.mot.com
電話：+1 847-632-6941電子メール：asingh1@email.mot.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。