[要約] RFC 4066は、Candidate Access Router Discovery（CARD）プロトコルに関するものであり、ネットワーク内のアクセスルーターの発見と選択を容易にすることを目的としています。CARDは、ユーザーが最適なアクセスルーターを選択するための情報を提供します。
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
1つのアクセスルーター（AR）から別のアクセスルーター（MN）のシームレスなIPレイヤーハンドオーバーを有効にするには、MNは、ハンドオーバーの開始前に候補ARS（CARS）のアイデンティティと機能を発見する必要があります。車の発見の行為には、車のIPアドレスを特定し、その能力を見つけるという2つの側面があります。このプロセスは、「候補アクセスルーターディスカバリー」（カード）と呼ばれます。IP層のハンドオーバーの時点で、その能力がMNの好みに適している車は、ハンドオーバーのターゲット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プロトコルにより、モバイルノードの次のハンドオーバーの候補であるアクセスルーターに関する情報の取得が可能になります。
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.
自動車の発見には、車のIPアドレスと、ハンドオーバー決定にモバイルノードが使用する機能を特定することが含まれます。モバイルノードに車の選択肢がある場合があります。モバイルノードは、ハンドオーバー候補に対するモバイルノードの要件と車の機能の一致に応じて1つを選択します。ただし、決定アルゴリズム自体はこのドキュメントの範囲外です。
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.
車の発見の問題声明は[TKCK02]に記録されています。このドキュメントでは、自動車の発見を実行するためにプロトコルが説明されています。セクション3では、自動車発見プロトコルの2つの主要な機能について説明します。セクション4では、カードプロトコル操作の中核部分について説明します。プロトコルメッセージ形式については、セクション5で説明します。セクション6では、セキュリティに関する考慮事項について説明し、セクション7にはプロトコルパラメーターの表が含まれています。付録Aには、アクセスポイントL2 IDとアクセスルーターIPアドレスの間に車のテーブルマッピングを動的に構築するための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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
アクセスネットワークに存在し、1つ以上のAPに接続されているIPルーター。ARはMNSへのIP接続を提供します。
Candidate AR (CAR)
候補者AR（車）
An AR to which an MN has a choice when performing IP-level handover.
IPレベルのハンドオーバーを実行するときにMNが選択できるAR。
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
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
カード開始トリガー
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トリガー。たとえば、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.
カードプロトコルは、次の機能を達成します。
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を聞くことができる場合、逆アドレス変換にはメカニズムが必要です。カードプロトコルのこの機能により、MNは、APの受信したL2 IDをAPに接続する関連車のIPアドレスにマッピングできます。車のIPアドレスを取得するために、MNはAPのL2 IDを現在のARに送信し、現在のARは関連する車のIPアドレスをMNに提供します。
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).
カードプロトコルにより、MNSは、関連する車のIPアドレスに対する1つ以上のAPSのL2 IDを解決できます。L2 IDは通常、MNによる操作中に発見され、潜在的なハンドオーバー候補です。さらに、カードを使用すると、MNSは、MNのハンドオーバー決定に影響を与える可能性のある利用可能な帯域幅などの車に関連する特定の機能を発見できます。さらに、このプロトコルにより、ARは車の機能を備えた地元の車のテーブル（セクション4.1）を維持することができます。このため、カードプロトコルは、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が車の住所と機能情報を取得できるようにするために、MNとその現在のARの間で使用されるカード要求とカードの返信メッセージには、それぞれ1つ以上のアクセスポイントのL2 IDと関連する車のIPアドレスが含まれている場合があります。オプションで、カードの返信メッセージには、車の機能情報も含めることができます。車の機能は、機能コンテナメッセージパラメーターで伝達される属性値ペアのリストとして指定されています。
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.
車と関連する機能に関する情報は、MNがIPハンドオーバー中にターゲットアクセスルーターの選択を実行するために使用できます。現在のARは、その車のテーブル（セクション4.1を参照）に従って返信し、リクエストを解決できない場合はリゾルバエラー（セクション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.
また、カードプロトコルにより、MNはオプションで、Card Requestメッセージに設定メッセージパラメーターを含めることにより、現在のARの関心能力に関する設定を示すことができます。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は車両を事前にろ過することができ、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 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は、MNが実装した唯一のインターフェイスであるため、IEEE802.11aインターフェイス固有の機能パラメーターのみに関心があることを現在のARに示す場合があります。MNの現在のARは、IEEE802.11A固有の機能を備えた車のみを送り返します。同様に、オプションの要件メッセージパラメーターを使用して、MNは現在のARに、特定のQoS制約を満たすことができる車にのみ関心があることを示している場合があります。ここで、MNは、オプションの要件メッセージパラメーターを使用して、QOS制約値をQOS制約値とともに現在のARに送信します。QOS制約は、属性値ペアとして示され、MNによってオリジー化されたカード要求メッセージに追加された要件メッセージパラメーターでカプセル化されています。要件メッセージパラメーターを使用して、目的の車の機能のカットオフ値を示すことができます。設定パラメーター内の属性のオプションのオプションリストまたは要件メッセージパラメーターの属性値ペアのリストによれば、MNの現在のARは、これらのパラメーターを使用して、求められたカード返信メッセージのコンテンツを決定することができます。MNに戻ります。あるいは、MNの現在のARが機能や車の事前フィルタリングに関して最適化を実行しない場合、現在のARは、カードリクエストメッセージで受信したオプションの要件と設定メッセージパラメーターを静かに無視することを選択する場合があります。
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には、カードリクエストメッセージに、MNが証明書を持っている信頼できるアンカーのリストが含まれ、ARは認証パスで応答します。一致が見つからない場合、ARはカードリクエストから信頼できるアンカー名を返します。MNは、現在のARまたは車のいずれかのチェーンを要求できます。信頼できるアンカーリストにMNの現在のAPのAP L2 IDが添付されている場合、返されたチェーンは現在のAR用です。L2 IDがスキャン中にMNが聞こえたAP用であり、現在のARに接続されていない場合、返されたチェーンは車用です。チェーンは、カード返信メッセージのシーケンス、単一の証明書、カードリクエストで送信されたAPのL2識別子、および車のルーターアドレス（またはAR自体のリクエストが作成された場合のルーターアドレスとして返されます。AR）。チェーンが完了すると、MNはそれを使用してARの認定キーを取得し、それによって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".
このセクションで説明されているように、カードプロトコル操作は、MNとその電流の間で交換されるシグナリングメッセージとARの間で交換されたものと区別します。したがって、次のセクションのシグナリングメッセージの説明には、関連するインターフェイスを参照する識別子が前にあります。MNとARの間で交換されるメッセージは「MN-AR」として指定され、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開始カードプロトコルの概要
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は、MN-ARカードリクエスト/返信プロトコルとAR-ARカードリクエスト/返信プロトコルの操作について説明します。アクセスポイントのL2 IDまたはカード開始トリガー（1M）の外観を受け取ると、MNはMN-ARカード要求メッセージ（2M）を使用して1つ以上のAP L2 IDを現在のARに渡すことができます。MNがARに逆アドレスの翻訳に加えて機能の発見を実行することを望んでいる場合、これはC-FLAGを設定してMN-ARカード要求メッセージに示す必要があります。C-FLAGが設定されていない場合、カード要求メッセージを受信するARは逆のアドレス変換のみを実行します。MNの現在のARは、L2 IDを関連車のIPアドレスに解決します。MNがL2 IDメッセージパラメーターを添付していない場合、逆アドレスの翻訳情報（L2 IDからIPへのすべてのCARSのIPアドレス情報を読み取ります地元の車のテーブルからのアドレスマッピング）。現在のARは、MN-ARカードの返信メッセージ（3M）、車のIPアドレス、L2 IDサブオプションステータスフィールドに示されている候補のL2 IDの各車のIPアドレス、および機能の場合、MN-ARカード応答メッセージ（3M）を使用してMNに戻ります。関連する機能が要求されています。
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カードのリクエスト/返信プロトコルの場合、リクエストARは、車のテーブルエントリがタイムアウト（1A）になったときにカード要求メッセージをピアに送信します。ピアは、要求された情報（2A）でカードの返信メッセージを返します。
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.
ARSは、関連する車のIPアドレスに対する候補APSのL2 IDを解決するために使用されるL2-L3アドレスマッピングテーブル（車テーブル）を維持するものとします。デフォルトでは、このアドレスマッピングテーブルは、カードプロトコル操作用に静的に構成されています。オプションで、車のテーブルに動的に入力される場合があります。2つの考えられるアプローチについては、付録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.
ARSは、関連する機能の寿命を考慮して、地元の車のテーブルに個々の車の機能を維持および維持する必要があります。個々の機能エントリの寿命が切れた場合、それぞれの機能情報が更新されます。ARは、車のテーブル内の車に関連する機能の有効期限が満たされる前に、能力交換を開始し、それによって車のテーブルに住むこともあります。ARの車のテーブルは異なる方法で実装される場合があります。したがって、追加の詳細はここでは提供されません。ARSは、MNがARの認証パスを取得できるように、新しく起動されたMNSにこの情報を提供するために、駐車場に独自の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.
MNSは、同じ情報を繰り返しリクエストしないように、ローカルキャッシュ内の車の発見された住所と能力情報を維持し、ハンドオーバーが差し迫っているときにできるだけ早く車のリストから適切なターゲット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.
カードを開始するために、MNは現在のARにカード要求を送信し、近くのアクセスポイントのL2 IDを関連する車のIPアドレスに解決し、これらの車に関連付けられた機能パラメーターを取得するよう要求します。要求MNが現在のARに特定のL2 IDを解決することを望んでいる場合、MN-ARカード要求には、カードプロトコル固有のL2 IDメッセージパラメーターを含める必要があります。MNがARに車の機能を追加せずに逆アドレス変換のみを実行することを望む場合、MNはカードリクエストメッセージにCフラグを設定することを控えます。MNが機能の発見を実行したい場合、MNはカード要求メッセージにC-Flagを設定する必要があります。カードリクエストには、設定または要件メッセージパラメーターも含まれている場合があります。これは、関心のある能力属性に関するMNの設定またはCARSの機能属性値ペアに関する要件を示しています。
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が複数のL2 IDサブオプションをカード要求に追加する場合、ARは各L2 IDが別の車に接続するAPに関連付けられていると仮定する必要があります。L2 ID、アドレス情報、および機能情報は個別のサブオプションで送信されるため、各サブオプションにはコンテキストIDが搭載され、一緒に属するパラメーターが一致するようにします。したがって、MNは、Card Requestメッセージに追加されたL2 IDサブオプションに異なるコンテキストID値を割り当てる必要があります。L2 IDサブオプションのステータスコードフィールドは、MNによって常にNONE（0x00）に設定する必要があります。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カードの返信メッセージを受信すると、MNはカードの返信を適切なカード要求メッセージと相関させ、すべてのMN-ARカード返信メッセージパラメーターを処理して、車の住所と機能情報を取得します。MNが以前に送信されたカードリクエストメッセージとカードの返信を相関させることができない場合、MNは回答を静かに廃棄する必要があります。これは、接続されたARにカード要求メッセージを送信した後にMNの再起動が発生する可能性があります。
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秒以内にカードの返信が受信されない場合に、指数バックオフを使用してカードリクエストを再送信します。再送信されたカード要求は、元のカードと同じシーケンス番号を持っている必要があります。本質的に大きい認証パスを除き、ARはカードの返信の情報を単一のメッセージへの情報を制限しようとする必要があります。それが不可能な場合、ARは複数のメッセージで返信を送信する場合があります。返信の最後のメッセージには、メッセージが関連するシーケンス番号の最後であることを示すために、カード返信オプションにL-Flagを常に設定する必要があります。カードリクエストへのARの再送信返信は、常に完全なカード返信シーケンスを送信する必要があります。信頼できるアンカーサブオプションとルーター証明書サブオプションは、認証パスを運ぶカードの返信が複数のメッセージにまたがり、そのうちの1つが失われた場合に、MNが認証パスで特定の証明書を要求できる手段を提供します。ただし、最初のカード返信で受信されなかった特定の証明書のリクエストは、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は特定の車の解決されたIPアドレスをL2 IDに割り当てることができます。
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パラメーターがカード返信メッセージに存在します。L2 IDパラメーターのステータスコードフィールドは、MNに送られる理由の1つを示しています。
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.
リゾルバーエラーステータスコードの表示：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 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.
マッチステータスコードの表示：以前に解決されたL2 IDと車を共有するL2 IDが遭遇した場合、ARはMNに一致します。このステータスコードは、この特定のL2 IDサブオプションのコンテキストIDが、関連する車のアドレスと機能コンテナサブオプションのコンテキストIDに設定されており、このカード返信メッセージで送信されたことを示しています。このアプローチでは、同じ車の住所と機能情報を同じカード返信メッセージで複数回送信して、2つ以上のL2 IDが同じ車に解決した場合に備えています。MNは、L2 IDサブオプションで受信したコンテキストIDをキーとして使用して、受信したカード返信メッセージのコンテンツから与えられたAPのサービングカーを見つけます。
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.
候補ステータスコードの表示：MNがL2 IDをカード要求に追加しない場合、ARはL2 IDを送り返し、すべての車のアドレス情報を送信します。受信したパラメーターのコンテキストIDは、以前に送信されたリクエストのL2 IDのコンテキストIDと相関することができないため、ARはコンテキストIDの値を選択し、これらの候補L2 IDを分散型L2 IDのステータスコードで候補とマークします。ただし、L2 IDSのコンテキスト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は、要求されたAPSのL2 IDを関連する車のIPアドレスに解決するものとします。MN-ARカード要求メッセージでL2 IDパラメーターが送信されていない場合、受信ARはすべてのCARSのIPアドレスを取得し、C-FLAGがリクエストに設定されている場合、機能情報を取得します。
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はL2 IDを要求MNに送り返しません。ただし、2つ以上のL2 IDが同じ車の情報と一致する場合、L2 IDサブオプションがMNに送り返され、L2 IDのステータスコードフィールドの一致が示されます。さらに、ARは、返されたL2 IDのコンテキストIDを、解決された車のL2 ID、アドレス、および機能コンテナサブオプションの値に設定します。ARが特定のL2 IDを解決できない場合、L2 IDサブオプションがMNに送り返され、L2 IDサブオプションのステータスコードフィールドのリゾルバエラーが示されます。
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がカード要求を伴うL2 IDを受け取らなかった2番目のケースでは、すべての候補APSのL2 IDがカード返信メッセージを使用して要求MNに送信されます。ARは、個々のL2 IDのステータスコードを候補としてマークし、関連するコンテキストIDが以前に送信されたリクエストのIDと一致できないことをMNに示します。
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.
オプションでは、ローカルポリシーで許可され、能力発見のためにそれぞれのARSによってサポートされる場合、ARは機能または車のサブセットを取得し、地元の車のテーブルからオプションに追加された設定と要件メッセージパラメーターを満たすことができます。Carsのアドレス情報と関連する機能は、MN-ARカードの返信メッセージを使用してMNに配信されます。CARSのIPアドレスと機能は、このドキュメントのセクション5.1.3で定義されているように、カードプロトコルメッセージパラメーターの形式に従ってエンコードされます。機能は、セクション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は、MN-ARカードリクエストを受け取ったとき、または1つ以上のローカルカーテーブルの機能エントリの寿命が期限切れになっていることを検出したときの車との能力交換を開始する場合があります。ARは、自動車のテーブルを優先的に利用して、車に直接信号を送るのではなく、リクエストを満たす必要があります。また、MN応答に不必要な遅延を注入しないように、この目的のために最新の車のテーブルを維持する必要があります。
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.
ARは、現在のARの車テーブルで車の完全な機能情報が利用できない場合、またはそのような情報が期限切れまたは期限切れになっている場合、それぞれの車にAR-ARカード要求を発行する必要があります。AR-ARカード要求メッセージ形式は、セクション5.2.2で定義されています。AR-ARインターフェイスのシーケンス番号は、ARが再起動するとゼロから始まります。送信ARは、カード要求メッセージを送信するたびに、カードリクエストのシーケンス番号を1つずつ増分する必要があります。
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カード要求に追加する可能性があります。AR-ARカード要求が現在のARの機能を車に伝える場合、関連する機能コンテナは、受信車がこのフィールドを処理する必要がないため、コンテキストIDに任意の値を設定できます。L2 IDおよびアドレスサブオプション。さらに、現在のARは、CALD CONTOCOL MESSAGE PIGGYBACKINGを実行する独自の機能について車に通知するために、CAFABITIONコンテナサブオプションにP-FLAGを設定する場合があります。
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は、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.
MNの現在のARは、以前に送信されたリクエストに応じて車から送信されるAR-ARカードの返信を受け取ったときに、受信したメッセージのペイロードから機能情報を抽出し、受信した機能をローカルの車のテーブルに保存するものとします。個々の機能の寿命は、受信した各機能に示されている生涯に従って設定されます。テーブルエントリのタイムアウトの値は、個々の機能の性質に依存するものとします。
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.
オプションで、車はAPSまたは機能の構成が動的に変更された場合、グローバルに隣接するARSに承認のないカード返信メッセージを送信できます。現在のARがローカルの車テーブルにエントリがある車から未承諾カードの返信メッセージを受信した場合、現在のARは、受け取ったカードの返信のシーケンス番号が以前に受け取った未承諾カードの返信と比較して増加していることをチェックします同じ車から送信されたメッセージ。次に、現在のARは、受信した機能に応じてローカルの自動車テーブルを更新できます。新しい車が追加された場合、ARは車のテーブルにない車や再起動した車からカードの返信を受け取ることができます。この場合、シーケンス番号は0です。ARSがセクション6で詳述されているIPSECセキュリティ協会を共有する要件は、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 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カードのリクエストを受け取ると、送信ARにその機能が含まれている場合、車は送信ARの機能を抽出するものとします。車は、受信した機能を車のテーブルに保管し、個々の機能のタイマーを適切に設定するものとします。テーブルエントリのタイムアウトの値は、AR-ARカードの返信メッセージの機能の性質に依存します。車には、AR-ARカードリクエストメッセージで受信したものと同じシーケンス番号をAR-ARカード返信メッセージに含める必要があります。AR-ARカードの返信には、CARの機能が機能コンテナメッセージパラメーターに属性値ペアのリストとして含まれているものとします。送信ARがオプションの設定サブオプションを追加した場合、CARは機能フィルタリングを実行し、設定サブオプションに従って識別される要求ARに関心のある機能のみを送信する場合があります。AR-ARカードの返信は以前に受信したAR-ARカードリクエストに基づいているため、車はAR-ARカードのUフラグを0に設定する必要があります。
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.
オプションで、車は、その機能パラメーターの1つ以上が変更された場合、グローバルに隣接するARに未承諾カードの返信メッセージを送信する場合があります。各未承諾カードの返信メッセージには、宛先アドレスとして隣接するARのユニキャストアドレスがあり、U-Flagセットが必要です。連続した未承諾カードの返信メッセージには、ARブーツのときに0から始まるシーケンス番号がそれに応じて増加する必要があります。
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.
カードは、高速ハンドオーバープロトコルメッセージで機能が選択されている別の自動車情報配信をサポートします。MNSおよびARSがICMP-Optionタイプカードリクエストとカードの返信をICMPタイプの高速モバイルIPv6 [Kood03]シグナル伝達に追加するために、MNとARはカードプロトコルのシグナリングピアの機能を知っておく必要があります。メッセージピギーバック。これには、MN-ARカード要求とMN-ARカードの返信メッセージ、および機能コンテナメッセージパラメーターでのP-FLAGを使用して、ピギーバック機能の動的な発見が必要です。これらのメッセージとパラメーターの形式は、セクション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.
MNは、セクション4.2.1で説明されているように、輸送用のICMPタイプカードメインヘッダーを使用して、最初のカード要求を現在のARに送信します。MNがカードプロトコルメッセージをサポートする場合、この最初のカード要求メッセージのP-FLAGが設定されます。カード要求メッセージを受信すると、現在のARはMNのピギーバック機能について学びます。ピギーバック機能を示すために、ARはカード返信メッセージにP-Flagを設定します。ARがピギーバックをサポートしていない場合、MNとARの間の後続のカードプロトコルメッセージはすべて、カードメインヘッダーを使用してスタンドアロンで送信されます。両方のノード（MNとその現在のAR）がカードプロトコルメッセージをサポートする場合、後続のカードプロトコルメッセージは、プロキシ（RTSOLPR）およびプロキシルーター広告（PRRTADV）メッセージのための高速モバイルIPv6ルーターの勧誘を介してオプションとして伝達できます。カードプロセス中に、MNは、セクション5.1.3.4で説明）にもP-Flagが含まれているため、発見フェーズで車のピギーバック機能について学びます。これにより、MNは、この車がカードプロトコルピギーバックをサポートしていると仮定して、選択した車へのハンドオーバーの直後にカードプロトコルメッセージを実行できます。
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プロトコルの逆アドレス変換機能を好む場合、カードプロトコルメッセージピギーバックを使用して、車の機能情報のみを取得できます。逆アドレスの翻訳が不要であることを示すには、ピギーバックされたカード要求メッセージにはA-Flagセットが必要です。これにより、現在のARは機能コンテナのサブオプションのみを追加します。適切な車のカード返信メッセージのパラメーターとして送信される機能コンテナを関連付けるには、個々の機能コンテナのコンテキストIDをインデックスとして使用して、PRRTADVメッセージオプションの関連するIPアドレスを指している必要があります。。個々の機能コンテナのコンテキストIDは、MNの現在のARによって適切に設定されています。PRRTADVメッセージの特定のIPアドレスオプションに個々のコンテキストID値をどのように関連付けることができるかの詳細は、このドキュメントの範囲外です。
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にはシグナリングが失われた場合、パケットを再送信するための規定が含まれていないため、カードプロトコルにはMN-ARインターフェイスの輸送パフォーマンスを改善するための規定が組み込まれています。ICMPにはIPレベルを超える断片化の規定がないため、MNSは単一の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).
MNSとARSは、ICMPタイプの高速モバイルIPv6 [Kood03]を介してカードプロトコルメッセージを伝達できない場合に、実験的ICMPタイプのメインヘッダー[KE04]を使用します。MN-ARインターフェイスは、輸送にカードICMPタイプのヘッダーを実装する必要があり、使用する必要があります。利用可能な場合、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 ...
+-+-+-+-+-+-+-+-+-+-+-+- - - -
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]).
タイプ：実験的モビリティタイプ（IANAによってIPv4およびIPv6に割り当てられ、[ke04]を参照）。
Code: 0
コード：0
Checksum: The ICMP checksum.
チェックサム：ICMPチェックサム。
Subtype: Experimental Mobility subtype for CARD; see [Ke04].
サブタイプ：カードの実験的モビリティサブタイプ。[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.
カードリクエスト：カードリクエストにより、エンティティはARSからカード固有の情報を要求できます。受信者側のカード要求メッセージの処理をサポートするために、さらにサブオプションを携帯する場合があり、逆のアドレス変換機能および/または機能発見機能への入力として機能します。
CARD Reply: The CARD Reply carries parameters, previously requested with a CARD Request, back to the sender of the CARD Request.
カードの返信：カードの返信には、以前にカードリクエストでリクエストされたパラメーターが、カードリクエストの送信者に戻ります。
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アドレスとIPアドレスとその場合に関連する車に関連付けられたアクセスポイントのレイヤー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.
機能コンテナ（必須）：機能コンテナサブオプションには、単一の車の機能に関する情報が含まれています。このサブオプションの形式は、セクション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.
アドレス（必須）：アドレスサブオプションには、個々の車の解決された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または車のパスに1つの証明書を搭載しています。チェーンには、ARがMNと共通する信頼できるアンカーから始まる証明書が含まれています。ルーター証明書サブオプションの形式については、セクション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を参照してください。このサブオプションは、オプションの機能がARSで実行される場合にのみ使用され、要求する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特定の属性値ペアを伝え、MNの現在のARが要求のMNに関心のある車に関する情報のみを送信できるようにします。CARは、CARSの機能パラメーターに従ってARSでフィルタリングされ、要件のサブオプションにエンコードされているように、ポリシーまたはしきい値が与えられます。属性値のペアは、セクション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_request_retry待機期間後に発生します。再送信は、指数関数的に増加する待機間隔で行う必要があります（毎回待機を2倍にします）。カードリクエストは、応答（エラーになる可能性がある）が取得されるか、card_retry_max秒が発生するまで再送信する必要があります。ARSは、card_retry_max秒後に同じシーケンス番号を持つカードリクエストを破棄する必要があります。カードの返信が複数の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.
カードリクエストを再送信するMNS同じカードシーケンス番号を使用します。これにより、ARは元のリクエストへの返信をキャッシュし、重複したリクエストが到着した場合に再度送信できます。このキャッシュされた情報は、リクエストを受け取ってから最大のcard_retry_max秒のみ保持する必要があります。シーケンス番号はランダムに選択する必要があります。MNSが頻繁に再起動する場合、ランダムシーケンス番号は重複を避け、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.| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
田畑：
Type: 8-bit identifier of the type of option, assigned by IANA. See [Ke04] for CARD Request and CARD Reply values.
タイプ：IANAによって割り当てられたオプションのタイプの8ビット識別子。カードリクエストとカードの返信値については、[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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Fields:
田畑：
Type: Assigned by IANA for IPv4 and IPv6; see [Ke04].
タイプ：IANAによってIPv4およびIPv6に割り当てられています。[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.
フラグ：P-Flag：カードプロトコルメッセージカードリクエストメッセージ送信者のピギーバック機能を示します。このフラグを適切に使用するための説明は、このドキュメントのセクション4.4に記載されています。
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.
C-Flag：要求エンティティが関連する車の機能にも関心があることを示します。MNがARに、対処情報に加えてカードの返信にCarsの機能パラメーターを追加することを望む場合、MNはこのフラグを設定する必要があります。
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.
A-Flag：要求エンティティがこのメッセージの受信者が逆アドレスの翻訳を実行することを望まないことを示します。このフラグは、カードプロトコルメッセージが逆のアドレス変換を実行するプロトコルでピギーバックされている場合に設定されます。詳細については、このドキュメントのセクション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-Flag：要求エンティティがレスポンダーからすべての証明書を取得することに関心があることを示します。このフラグは、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
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.
フラグ：P-Flag：カードプロトコルメッセージカード応答メッセージ送信者のピギーバック機能を示します。このフラグを適切に使用するための説明は、このドキュメントのセクション4.4に記載されています。
U-flag: Indicates an unsolicited CARD Reply. This flag is only valid on the AR-AR interface.
U-Flag：未承諾カードの返信を示します。このフラグは、AR-ARインターフェイスでのみ有効です。
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-flag：このメッセージが複数の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 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Sub-Option Type: 0x01
サブオプションタイプ：0x01
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.
ステータスコード：このフィールドにより、ARSは特定のL2 IDの結果の処理について要求するエンティティに通知できます。L2 IDサブオプションは、カード返信メッセージを使用して要求エンティティに送信する必要があります。
The following status codes are specified:
次のステータスコードが指定されています。
0x00: NONE - This value MUST be set when the L2 ID is included in a CARD Request.
0x00：なし - この値は、L2 IDがカードリクエストに含まれている場合に設定する必要があります。
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.
0x01：候補者 - L2 IDサブオプションが候補APSのL2 IDに関する情報に含まれている場合、カードの返信に設定する必要があります。カードリクエストに解像度のための特定のL2 IDが含まれていない場合、候補L2 IDが送信されます。候補者が設定されている場合、ARは、個々のパラメーターのコンテキストIDフィールドを、関連するL2 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.
0x02：一致 - カードの返信に設定する必要があります。このL2 IDは、以前に解決された車の情報が別のL2 IDについて一致していることを識別します。一致が設定されている場合、ARはL2-IDサブオプションにコンテキストIDを設定して、以前に解決された一致したL2 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タイプ：インターフェイスタイプを示します。IANA [KE04]によって割り当てられました。
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 ID：個々の車のアクセスポイントの可変長レイヤー-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type:
0x04
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を参照）フィールドのみが存在し、個々の機能に設定する必要があります。これは、リクエストエンティティにとって興味深いものです。Lifetime and Value（data）インジケーターは処理されず、省略できます。AVP長さのインジケーターも存在しません。これは、16ビットエンコードされた属性フィールドのリストでのみ設定が示されているため、存在しません。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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type: 0x05
サブオプションタイプ：0x05
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で説明したルールに従ってエンコードする必要があります。属性（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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Sub-Option Type: 0x03
サブオプションタイプ：0x03
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-Flag：この機能コンテナで機能が伝達される車のピギーバック機能を示します。このフラグにより、MNはカードプロセスの後に選択した新しいARがピギーバックを実行できるかどうかを知ることができます。
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.
AVPS：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 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -
Sub-Option Type: 0x02
サブオプションタイプ：0x02
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -
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.
コンポーネント：送信者が認定パスのすべての証明書を取得することを望んでいる場合、65,535に設定された2オクテットの署名されていない整数フィールド。それ以外の場合、受信者が取得したい証明書に対応するコンポーネント識別子に設定されます。
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.
信頼できるアンカーサブオプションを含むカード要求メッセージには、関心のある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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Octet Unsigned Integerは、認証パスの証明書の総数を提供します。
Component: 2 octet unsigned integer giving the location of this certificate in the certification path.
コンポーネント：2 Octet Unsigned Integerは、認定パスにあるこの証明書の位置を提供します。
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.
パディング：オプションの長さを8の倍数にする可変縦フィールド。ASN.1証明書のエンコード後に始まり、長さフィールドで指定されているように、オプションの最後まで継続します。
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.
ルーター証明書サブオプションを含むカード返信には、そのようなサブオプションを複数含める必要はありません。カードの返信には、コンテキストを使用してチェーンを所有するルーターの一致するL2 IDサブオプションとルーターアドレスアドレスサブオプションを含める必要があります。IDフィールドはゼロ以外の値に設定され、他のサブオプションはありません。カードの返信に含まれるその他のサブオプションは無視する必要があります。返信が複数のICMPメッセージにまたがる場合、L2 IDサブオプションとルーターアドレスサブオプションを最初のメッセージに含める必要があり、すべてのメッセージのルーター証明書サブオプションのコンテキストIDフィールドをに設定する必要がありますL2 IDおよびアドレスサブオプションの値と同じ値。返信ARは、即時の検証を許可するために、パスの信頼アンカーの直後に証明書が最初に送信されるように、返された認証パスを注文する必要があります。Trust Anchor証明書自体を送信しないでください。
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 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
AVP Code: Identifies the attribute uniquely. The AVP Code 0x0000 is reserved and MUST NOT be assigned to a capability.
AVPコード：属性を一意に識別します。AVPコード0x0000は予約されており、機能に割り当てられてはなりません。
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.
Lifetime：エンコードされた機能の寿命を秒単位で指定します。静的能力の場合、寿命フィールドは最大値（0xffff）に設定する必要があります。これは、この機能パラメーターの寿命が期限切れになることを示しています。0x0000の生涯値は、機能エントリを削除します。
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.
カードが役立つ可能性のあるアクセスネットワークの種類は現在展開されていないか、展開されている場合、広範囲に測定されていないため、混雑がルーター間カードの問題になるかどうかを知ることは困難です。標準化の可能性のある候補者として検討するためにカードを準備する研究タスクの一部は、この問題を定量化することです。ただし、生産アプリケーションへの潜在的な干渉を回避するために（プロトタイプカードの展開がパブリックインターネット上での実行を伴う場合）、混雑に対応するデフォルトのトランスポートプロトコルを推奨することは賢明のようです。
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ペイロードデータチャンクには、カードメッセージが含まれます。ルーター間インターフェイスのカードメッセージは、カードリクエストまたはカードの返信オプションのみで構成されています。各SCTPメッセージのユーザーデータ部分には、メッセージタイプのカードオプションが含まれています。たとえば、カード返信メッセージは、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メッセージのシーケンス配信を備えたカードに使用されます。各メッセージは、断片化されていない限り、単一のカードクエリまたは応答に対応します。未承諾カードの返信メッセージをピアに送信して、ネットワーク構成または機能の変更を通知することもできます。単一のストリームはシンプルさを提供します。一次遮断を防ぐために複数のストリームを使用することは、将来の研究のためのものです。適時性はルーター間カードの問題ではないため、2つのルーター間に一度にアクティブに複数のカードトランザクションがあるため、配信を注文すると実装が簡素化される可能性が低いためです。SCTPヘッダーのペイロードプロトコル識別子は「カード」です。カードは、Seamoby SCTPポート番号[KE04]を使用します。
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) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'U' bit The Unordered bit. MUST be set to 0 (zero). 'B' bit The Beginning fragment bit. See [Stew00].
「u」は順序付けられていないビットをビットします。0（ゼロ）に設定する必要があります。「b」ビット開始フラグメントビット。[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'.
「カード」に設定されたペイロードプロトコル識別子。
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は、再起動時に0からCARD_STARTUP_WAIT秒の間にランダムな時間を待ってから、AR-ARカードリクエストを1つの車に送信する必要があります。車のテーブルにない別のARからカードリクエストを受信するARは、ARを勧誘してはなりませんが、ARがARの情報を宣伝する未承諾カードの返信を送信するまで待たなければなりません。起動しているARは、すべての車に未承諾カードの返信を送信して、車のテーブルが適切に埋め込まれていることを確認する必要があります。
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_min_update_intervalに厳密に制限する必要があります。ARは、より頻繁に到着するメッセージを自由に破棄できます。
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.
カードの展開がパブリックインターネット上で実行されない場合、および輻輳がアクセスネットワークで問題でないことがわかっている場合、代替輸送プロトコルは実験に適した車両になる可能性があります。カードの実装は、そのような目的でUDPをサポートする場合があります。その場合、研究者は、指数関数的なバックオフで再送信を使用するなど、優れたインターネット輸送プロトコルエンジニアリングの実践に注意する必要があります。さらに、SCTPがすべてのルーター間カード操作に適したトランスポートプロトコルであるかどうかは、オープンな研究問題です。この問題の調査（たとえば、軽量プロトコルが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ユーザーデータフィールドの本文に直接カードリクエストオプションとカード返信オプションを挿入する必要があります。AR-ARインターフェイスのカード要求のシーケンス番号は、AR再起動時にゼロに初期化する必要があり、カードリクエストメッセージが送信されるたびにインクリメントする必要があります。返信ARには、カード返信のカード要求からのシーケンス番号を含める必要があります。未承諾カードの返信が送信された場合、送信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インターフェイスでは、ARS間の機能を伝達するために機能コンテナパラメーターを使用します。オプションで、設定パラメーターは、AR Inter-AR機能発見手順中に機能を事前にフィルタリングするために使用できます。ペイロードタイプとエンコードルールは、MN-ARインターフェイスのセクション5.1のそれぞれのサブオプションタイプについて説明したものと同じです。同じTLVエンコード形式を使用して、プロトコルメインヘッダーにペイロードとしてオプションを添付します。さらに、ARは、車の証明書を取得するために、カード要求ヘッダーに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.
カードプロトコルの真実性は、ARが地理的に隣接するARに関する正確な情報を取得し、他のARに独自のAPと機能に関する正確な情報を提供する能力に依存します。このドキュメントの本文で説明されているカードプロトコルには、特定のARまたは車のAR-APマッピングまたは機能を決定するためのサポートは含まれていません。したがって、AR間で交換される情報の精度を決定する方法は、ベースカードプロトコルの範囲外です。このドキュメントの付録は、地理的に隣接するARSおよびAPS（機能を含む）のアイデンティティを発見するための手順について説明し、関連するセキュリティに関する考慮事項について説明します。あるいは、この情報は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.
カードには、ARSが機能情報を交換できるようにするサポートが含まれています。このプロトコルが変更から保護されていない場合、悪意のある攻撃者は情報を変更できます。また、情報が平易なテキストで配信された場合、第三者はそれを読むことができます。
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.
情報が侵害されないようにするには、AR間のカードメッセージを認証する必要があります。また、メッセージは、必要に応じて情報のプライバシーのために暗号化する必要があります。たとえば、オペレーターのネットワーク内の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.
カードプロトコルに従事する2つのARは、IKE [HARCAR98]を使用して、メッセージ認証のためにIPSEC ESPセキュリティ協会を交渉する必要があります。機密性が必要な場合、2つのARは、暗号化のためにESPセキュリティ協会とさらに交渉する必要があります。再生保護もIKEで有効にする必要があります。ARS間のカードプロトコルメッセージを保護するには、IPSEC ESP [ATKE98]を非ヌルの整合性保護および原点認証アルゴリズムで使用する必要があり、カード情報の機密性を保護するために非ヌル暗号化アルゴリズムで使用する必要があります。
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は、カード要求メッセージに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.
さまざまな管理ドメイン間の情報を交換するためにカードを使用すると、追加のセキュリティポリシーの問題が適用される場合があります。このような問題は、このドキュメントの範囲外です。現時点では、管理ドメイン間のカードの使用は、関係するポリシーの問題がより完全に理解されるまで推奨されません。
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を装ってMNSに偽のカード返信メッセージを送信できます。MNは、ARからのカード返信メッセージを認証する必要があります。MNとARの間にIPSECセキュリティ協会を確立することはパフォーマンスの問題である可能性が高いため、IKEはセキュリティ協会を設定するための適切なメカニズムではありません。代わりに、Send Security Associationが使用されます[arkko04]。ARSには、カード返信メッセージに送信署名オプションを含める必要があります。署名オプションの形式はIPv4カードとIPv6カードの両方で同じですが、送信自体はIPv6に対してのみ定義されます。送信署名オプション[KE04]のモバイルIPv4 ICMP Foreign Agent Advertisementオプションタイプコードが割り当てられています。
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によってカード情報が提供されるためです。対照的に、偽の返信認証が必要です。偽のARは、MNが偽のルーターに引き渡すように導くカード情報をMNに提供できるため、MNへのサービス攻撃の拒否を伝播する可能性があります。認証要件の非対称性は、IPv6ルーターの発見にルーター広告を含むものと同じです[Arkko04]。
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.
カードはディスカバリープロトコルであるため、MN-ARインターフェイスでは一般的に機密性は必要ありません。異なるネットワークオペレーターが同じアクセスネットワークインフラストラクチャを共有する特定の場合、ネットワークオペレーターは、ビジネス上の理由でオペレーター固有の機能に関する情報を非表示にすることができます。ベースカードプロトコルには、そのような場合のサポートが含まれていません。ただし、そのようなケースが将来発生した場合、暗号化された機能の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].
送信はIPv6でのみ利用可能であるため、証明書を取得する手順は、カードがIPv4またはIPv6で使用されるかどうかによって異なります。IPv6では、MNが証明書を持っていないARから署名を含むカードの返信を受信する場合、DCS/DCAを送信してARの証明書チェーンを取得する必要があります。ARSはこの目的のために認証パスで構成する必要があり、MNSは、AR証明書の検証を可能にするために、共有された信頼できるアンカーの証明書のセットで構成する必要があります。MNは、カードで暗号化されたアドレス（CGA）を必ずしも使用する必要がない場合があるため、CGAサポートはカードにオプションです。ARSの証明書プロファイルは、送信仕様[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と1つの信頼できるアンカーサブオプション（セクション5.1.3.6）を含むカード要求メッセージを送信します。現在のARの認証パスを取得するための証明書。信頼できるアンカーサブオプションのコンポーネントフィールドは65535に設定されており、認証パス全体が必要であることを示します。リクエストに他のオプションを含めるべきではありません。ARは、リクエストに送信されたL2 IDサブオプション、それ自体のアドレスサブオプション、および一致する認定パスに1つの証明書を含むルーター証明書サブオプション（セクション5.1.3.7）を含むカードの返信を送信することで返信します。要求された信頼のアンカーの1つ、およびその他のサブオプションはありません。すべてのサブオプションのコンテキストIDを一致させます。すべてのコンポーネントフィールドはパス長に設定され、コンポーネントフィールドはパス内のこのコンポーネントの数に設定されます。パスが1つの証明書よりも長い場合、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.
車の認証パスは、カードプロトコルの一部としてそれらを要求することにより、ハンドオーバーの前にフェッチすることができます。その場合、MNには、カード要求に信頼できるアンカーサブオプションと、CAR証明書が望まれるAPのL2 IDサブオプションと、ARが上記のように応答します。証明書は、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は、カードリクエストメッセージで圧倒される可能性があります。ARは、期間ごとに特定の数のメッセージを送信または処理しないように、レート制限ポリシーを実装する必要があります。以下は、推奨レート制限ポリシーです。カードメッセージの数がcard_request_rateを超える場合、ARはレートが低下するまでメッセージをランダムにドロップし始めるはずです。MNSは、card_request_rateよりも頻繁にメッセージを送信することを避ける必要があります。ARSは、CARD_MIN_UPDATE_INTERVALよりも頻繁に未承諾カードの返信またはカード要求を送信することも避ける必要がありますが、この場合、IPSECセキュリティ協会の存在により、未知のエンティティからのメッセージがIPSEC処理中にすぐに廃棄されるようになります。
MNs MUST discard CARD Replies for which there is no outstanding CARD Request, as indicated by the sequence number.
MNSは、シーケンス番号で示されるように、未解決のカードリクエストがないカードの返信を破棄する必要があります。
To protect against replay attacks on the AR-AR interface, ARs SHOULD enable replay protection when negotiating the IPsec security association using IKE.
AR-ARインターフェイスに対するリプレイ攻撃から保護するために、ARSはIKEを使用してIPSECセキュリティ協会を交渉する際にリプレイ保護を可能にする必要があります。
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は、シーケンス番号によって決定されるように、未解決の要求がないカード返信を破棄する必要があります。ARSの場合、攻撃者は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.
card_startup_wait 5.2.1 1-3秒最大起動物AR-ARカードを実行する前にARを待ちます。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV。Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[AtKe98] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ATKE98] Kent、S。およびR. Atkinson、「IPがセキュリティペイロードをカプセル化する（ESP）」、RFC 2406、1998年11月。
[HarCar98] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[Harcar98] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[Ke04] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[Ke04] Kempf、J。、「Seamoby and Experimental Mobility Protocol Ianaの割り当ての指示」、RFC 4065、2005年7月。
[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.、Kempf、J。、「シームレスなIPレベルのハンドオフの候補アクセスルーター発見の問題」、進行中の作業。
[MaKo03] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[Mako03] Mather、J。およびM. Kojo、「Mobility関連用語」、RFC 3753、2004年6月。
[Kood03] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[Kood03] Koodli、R.、ed。、「モバイルIPv6用の高速ハンドオーバー」、RFC 4068、2005年7月。
[Funa02] Funato, D., et al., "Geographically Adjacent Access Router Discovery Protocol", Work in Progress.
[Funa02] Funaato、D.、et al。、「地理的に隣接するアクセスルーター発見プロトコル」、進行中の作業。
[Tros03] Trossen, D., et al., "A Dynamic Protocol for Candidate Access-Router Discovery", Work in Progress.
[Tros03] Trossen、D.、et al。、「候補アクセスルーター発見のための動的プロトコル」、作業進行中。
[ShGi00] Shim, E. and R. Gitlin, "Fast Handoff Using Neighbor Information", Work in Progress.
[Shgi00] Shim、E。、およびR. Gitlin、「近隣情報を使用した高速ハンドオフ」、進行中の作業。
[Malk03] El Malki, K., et al., "Low Latency Handoffs in Mobile IPv4", Work in Progress.
[Malk03] El Malki、K.、et al。、「モバイル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.
著者は、Vijay Devarapalli（Nokia）とHenrik Petander（Helsinki University of Technology）に、プロトコル仕様文書を正式にレビューし、技術的な議論のための貴重なコメントと入力を提供してくれたことに感謝します。著者はまた、James Kempfにレビューし、多くの貴重なコメントと編集ヘルプを提供してくれたことに感謝したいと思います。
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.
著者は、（アルファベット順）ダーク・トロッセン、ゴビン・クリシュナムルティ、ジェームズ・ケンプフ、マジッド・ナクジリ、ピート・マッキン、ラジー・クッドリ、ロバート・C・チャルマーズ、およびシーモビーWGの他のメンバーに感謝します。文書、および一般的なカード関連の議論とフィードバックのため。さらに、著者は、高速モバイルIPv6メッセージのカードオプションの選択に関する貴重な洞察を提供してくれたErik Nordmarkに感謝したいと思います。
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つのオプションの車テーブルメンテナンススキームに関する情報を提供します。これらのスキームは、車のテーブルのAP L2 IDから車へのIPアドレスマッピングの静的構成を置き換えます。これらのメカニズムの詳細は、このドキュメントの範囲外です。この付録の意図は、このドキュメントで説明されているように、カードプロトコルの柔軟な拡張機能に関する基本的なアイデアのみを提供することです。
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が逆アドレスの翻訳を実行するのを支援します。集中化されたアプローチでは、隣接するARSがカードサーバーに登録して、逆のアドレス翻訳テーブルに登録する必要があります。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スキャン中にAPSのL2 IDを発見すると、1つ以上のL2 IDを現在のARに渡し、ARはそれらをARのIPアドレスに解決します。このため、ARは最初に、マッピング情報が自動車テーブルでローカルに利用可能であるかどうかを確認します。そうでない場合、MNの現在のARはL2 IDを備えたカードサーバーをクエリします。これに応じて、カードサーバーは車のIPアドレスを現在のARに返します。次に、現在のARはそれぞれの車に直接接触し、能力の発見を実行します。現在のARは、車のIPアドレスと関連する機能をMNに渡します。現在のARは、ローカルカーテーブル内に解決されたIPアドレスを保存します。集中型カードプロトコル操作は、MNの現在のARとカードサーバーの間で交換される追加の信号メッセージを導入します。ARとカードサーバー関数の間の信号メッセージは、関連するインターフェイスを参照する前の識別子「AR-Server」で表示されます。
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で説明されているように、MN-ARインターフェイス上でカードを実行します。ただし、MN-ARインターフェイスを介してルーターIDメッセージと呼ばれる追加のメッセージを使用して、ARSが隣接する逆アドレス翻訳表について学習できるようにします。ARS、集中サーバーに依存せずに。
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の車のテーブルの車のアイデンティティはソフト状態として維持されています。タイムアウト期間が失効する前にリフレッシュされず、次のメカニズムに従って作成または更新される車のテーブルからのエントリは、車のエントリが削除されます。
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 CARD and thus seamless handover using the CAR information. This idea was presented in [ShGi00] and [Tros03].
分散型アプローチの背後にある重要なアイデアは、入力として発生するMNSの実際のハンドオーバーを使用して、2つのARと互いの隣人としての関連性をブートストラップし、維持することです。隣接する2つのARS間の最初の引き渡しは、発見手順を呼び出すためのブートストラップハンドオーバーとして機能し、その後のハンドオーバーは、隣接するARの間の関連性をリフレッシュするのに役立ちます。ブートストラップのハンドオーバー後、MNSはカードを実行し、車の情報を使用してシームレスなハンドオーバーを実行できます。このアイデアは[SHGI00]および[TroS03]で提示されました。
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.
車のテーブルのメンテナンスは、MNとその現在のARの間で実行されるカードプロトコル操作に追加のオプションを使用して行われます。このメッセージは、ルーターのアイデンティティメッセージとして機能します。
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にルーターIDメッセージを送信する必要があります。このメッセージには、以前のAR（PAR）のID（IPアドレス）が含まれており、MN-ARカード要求メッセージの特定のサブオプションとして送信できます。MN-ARカードの返信で確認する必要があります。ルーターのアイデンティティメッセージにより、MNの現在のARは、PAR（Still）がカバレッジが現在のARのAPの1つと重複するAPを持っていることを知ることができます。この情報を使用すると、MNの現在のARは、隣接としてPARのエントリを作成または更新できます。2つのARの間でハンドオーバーが不可能な場合、関連するエントリは最終的にタイムアウトされ、各ARの車テーブルから削除されます。
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は、受信した情報の有効性を確保するために多くのチェックを実行する場合があります。簡単な方法の1つは、AR-ARカードリクエストメッセージをPARに送信して、ルーターIDメッセージの精度を確認することです。AR-ARカードリクエストには、MNのIDが含まれています。このメッセージを受信すると、PARは、合理的な過去の間隔中にMNが実際にそれに添付され、現在のARに応答したことを確認します。このようにして、MNの引き渡しごとに、2つの参加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は、該当するように、ローカルの自動車テーブルのPARのエントリを作成またはリフレッシュします。前者の場合、AR-ARカード要求とAR-ARカードの返信プロトコルメッセージを使用した現在の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.
最後に、ハンドオーバーベースのプロトコルでは、このハンドオーバーが車のテーブルをブートストラップするため、PARとMNの現在のARの間の最初のハンドオーバーはカードを使用できないことに注意してください。ただし、長期的には、このようなハンドオーバーは、2つのARの間で引き継ぎが成功したわずかなほんの一部になります。また、このような最初のハンドオーバーに従事するMNが、引き渡し時に非デレイに敏感なアプリケーションを実行している場合、ユーザーはその影響さえ認識しない場合があります。
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.
このセクションでは、カードプロトコル操作のアプリケーションシナリオの2つの例を示します。1つのシナリオでは、モバイルIPv6（MIPV6）ネットワークでのカードプロトコル操作について説明し、ワイヤレスLANアクセスポイントと関連するアクセスルーターを介してインフラストラクチャへのアクセスを提供します。2番目のシナリオでは、モバイルIPv6対応ネットワークでのカードプロトコル操作について説明します。これは、高速ハンドオーバー統合（高速モバイルIPv6）のサポートを強化し、インフラストラクチャへのワイヤレスLANアクセスも提供します。
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）APSを介してインフラストラクチャにアクセスできる移動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はAR1でサポートされているサブネット1のケアアドレスを保持しています。MNが移動すると、MNの現在の環境は、ハンドオーバーの候補APSとしてリンク品質が増加し、さらに2つのワイヤレスLAN APを提供します。意思決定を容易にするために、ARSに関連するパラメーターが決定プロセス中に考慮されます。AR関連のパラメーターは、たとえば、利用可能なQoSリソースまたはARからサポートされているアクセステクノロジーのタイプにすることができます。これらの候補ARSの機能と関連するIPアドレス情報について学習するために、MNはカードを実行します。これには、候補APSのL2 IDに関する情報を取得する必要があります。さらに、関連するリンク品質パラメーターが取得され、APに近づくことが引き継ぎの対象となる候補であるかどうかを確認します。AP2とAP3が適切な候補APSである場合、MNはL2 IDサブオプションを使用して両方の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は、L2 IDオプションにリストされている各L2 IDを、それぞれの車の関連するIPアドレスに解決し、ローカルの自動車テーブルを利用します。図B.1に示されている環境によると、候補AP2の関連するAR IPアドレスは、MNが現在添付されているのと同じです。これはAR1です。AP3が接続されている候補ARの対応するIPアドレスは、AR2のアドレスです。MNの車のIPアドレスは現在、AR1に知られており、車のテーブルから車の機能を取得しています。AR1の自動車テーブルの関連する寿命が切れる動的機能を更新するためのそれぞれの機能パラメーターの有効なエントリがあると仮定すると、AR1は機能発見のためにAR間カードを実行します。AR1の機能情報はAR1に知られているため、それぞれのAR間カード要求はAR2にのみ送信されます。これに応じて、AR2はカードの返信メッセージをAR1に送り返し、要求された機能パラメーターを能力コンテナサブオプションで信号メッセージを使用してカプセル化します。
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は独自の機能を送信し、AR2の動的に発見されたものは、カード返信メッセージを介してMNに戻ります。さらに、AR1は、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.
カードの返信メッセージを受信すると、MNはターゲットAR選択を実行し、AR1とAR2の機能パラメーターと関連するAPSのリンク品質パラメーターを考慮します。選択した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対応ネットワーク内のカードの前述のアプリケーションシナリオのシグナリングフローを示しています。
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ネットワーク内のカードプロトコル操作
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).
このアプリケーションシナリオは、ARSがモバイルIPv6 [Kood03]の高速ハンドオーバープロトコルシーケンスを実行できることを前提としています。図B.1と同様に、MNはハンドオーバーの新しいAPをスキャンします。ARS（CARS）を発見するために、MNはMNの現在のAR（PAR、前のAR）に送信されるICMPタイプの高速モバイルIPv6 RTSOLPRメッセージにMN-ARカード要求オプションを添付します。
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.)
候補APSのL2 IDは、カードプロトコルのL2 IDサブオプションを使用してカプセル化されます。これにより、MNは候補APの複数のL2 IDを現在のARに送信できます。（これは、高速モバイル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は、候補APSのL2 IDの受信したリストを、関連する車のIPアドレスに解決します。PARは地元の車のテーブルをチェックして、車の能力に関する情報を取得します。テーブルエントリが期限切れになった場合、PARはそれぞれの車にAR-ARカードリクエストを送信することにより、この車の機能を取得します。車はAR-ARカードの返信メッセージで返信し、機能コンテナサブオプションのすべての機能をカプセル化し、カード返信オプションに取り付けます。自動車の機能情報を受け取ったとき、PARはローカルの車のテーブルを更新し、MN-ARカード返信オプションを高速モバイルIPv6 PRRTADVメッセージに添付することにより、住所と機能情報をMNに転送します。MNのハンドオーバーが差し迫っている場合、MNは、発見された車のリストから新しいARと関連する新しいAPを選択します。高速モバイルIPv6プロトコルによると、MNは選択した新しいARのPARに高速バインディングアップデート（F-BU）メッセージを通知し、PARが高速モバイルIPv6プロトコルに従って高速ハンドオーバーを実行できるようにします。
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は、PARがMNの車のアドレスと関連する機能を利用できるようになった後、MNに代わって適切な新しいARの選択を実行できます。MNは、PARがMNの新しいARを選択した後、選択プロセスの要件をMN-ARカードリクエストメッセージとともにPARに送信する必要があります。高速モバイルIPv6 PRRTADVメッセージの返信オプション。
Figure B.3 illustrates how CARD protocol messages and functions work with the Fast Mobile IPv6 protocol.
図B.3は、カードプロトコルメッセージと関数が高速モバイル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
図B.3。カードプロトコルオプションを使用した高速ハンドオーバープロトコルシーケンス
* 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.
* 図B.3では、PARと車のテーブルの機能エントリの寿命が期限切れになった場合にのみ、PARとCARS間のカードプロトコルの相互作用が必要です。それ以外の場合、PARは、車のテーブルから車の住所と機能情報を取得した直後に要求MNに応答できます。
Authors' Addresses
著者のアドレス
Hemant Chaskar AirTight Networks 339 N. Bernardo Avenue Mountain View, CA 94043, USA
Hemant Chaskar Airtight Networks 339 N. Bernardo Avenue Mountain View、CA 94043、米国
EMail: hemant.chaskar@airtightnetworks.net
Daichi Funato NTT DoCoMo, Inc. Communication Systems Laboratory Wireless Laboratories 3-5, Hikarinooka, Yokosuka, Kanagawa 239-8536, Japan
Daichi Funato NTT Docomo、Inc。通信システム研究所ワイヤレス研究所3-5、Hikarinooka、横山、Kanagawa 239-8536、日本
Phone: +81-46-840-3921
EMail: funato@mlab.yrp.nttdocomo.co.jp
Marco Liebsch NEC Network Laboratories Kurfuersten-Anlage 36, 69115 Heidelberg, Germany
Marco Liebsch Nec Network Laboratories Kurfuersten-Anlage 36、69115 Heidelberg、ドイツ
Phone: +49 6221-90511-46
EMail: marco.liebsch@netlab.nec.de
Eunsoo Shim Panasonic Digital Networking Laboratory Panasonic Corporation Two Research Way Princeton, NJ 08540
Eunsoo Shim Panasonic Digital Networking Laboratory Panasonic Corporation Two Research Way Princeton、NJ 08540
Phone: +1-609-734-7354
EMail: eunsoo@research.panasonic.com
Ajoy Singh Motorola Inc 2G11, 1501 West Shure Dr. Arlington Heights, IL 60004, USA
Ajoy Singh Motorola Inc 2G11、1501 West Shure Dr. Arlington Heights、IL 60004、USA
Phone: +1 847-632-6941
EMail: asingh1@email.mot.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。