RFC4066 日本語訳
4066 Candidate Access Router Discovery (CARD). M. Liebsch, Ed., A.Singh, Ed., H. Chaskar, D. Funato, E. Shim. July 2005. (Format: TXT=116733 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Liebsch, Ed.
Request for Comments: 4066 A. Singh, Ed.
Category: Experimental H. Chaskar
D. Funato
E. Shim
July 2005
ワーキンググループM.Liebsch、エドをネットワークでつないでください。コメントのために以下を要求してください。 4066 エドA.シン、カテゴリ: 実験的なH.のChaskar D.船渡E.詰め物の2005年7月
Candidate Access Router Discovery (CARD)
候補アクセスルータ発見(カード)
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities and capabilities of candidate ARs (CARs) for handover prior to the initiation of the handover. The act of discovery of CARs has two aspects: identifying the IP addresses of the CARs and finding their capabilities. This process is called "candidate access router discovery" (CARD). At the time of IP-layer handover, the CAR, whose capabilities are a good match to the preferences of the MN, is chosen as the target AR for handover. The protocol described in this document allows a mobile node to perform CARD.
モバイルノード(ミネソタ)の1つのアクセスルータ(AR)から別のルータまでのシームレスのIP-層の引き渡しを可能にするのに、ミネソタが引き渡しの開始の前に引き渡しの候補ARs(CARs)のアイデンティティと能力を発見するのに必要です。CARsの発見の行為には、2つの局面があります: CARsのIPアドレスを特定して、彼らの能力を見つけます。 このプロセスは「候補アクセスルータ発見」(CARD)と呼ばれます。 IP-層の引き渡し時点で、CAR(能力はミネソタの好みへの良いマッチである)は引き渡しのための目標ARとして選ばれています。本書では説明されたプロトコルは、モバイルノードがCARDを実行するのを許容します。
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
1. 序論… 2 2. 用語… 3 3. カードプロトコルは機能します… 4 3.1. アドレス変換を逆にしてください… 4 3.2. 車の能力の発見… 4 4. カードプロトコル操作… 4 4.1. 概念的なデータ構造… 7 4.2. モバイルノード--ルータ操作にアクセスしてください… 8 4.3. 現在のアクセスルータ--候補アクセスルータ操作… 11 4.4. ミネソタ-ARインタフェースで便乗するカードプロトコルメッセージ… 13
Liebsch, et al. Experimental [Page 1] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[1ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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
5. メッセージについて議定書の中で述べてください… 14 5.1. モバイルノードアクセスルータへのカードメッセージは連結します… 14 5.2. カード相互アクセスルータメッセージ… 28 6. セキュリティ問題… 31 6.1. カード情報の真実性… 31 6.2. ARとARとのセキュリティ協会… 31 6.3. ARとミネソタとのセキュリティ協会… 32 6.4. ルータ証明書交換… 32 6.5. DoSは攻撃します… 34 6.6. 反射攻撃… 34 7. 定数について議定書の中で述べてください… 34 8. IANA問題… 35 9. 標準の参照… 35 10. 有益な参照… 35 11. 貢献者… 36 12. 承認… 36 アドレス・マッピングの付録A.メインテナンスはアクセスでルータを見送ります… 37 付録A.1。 サーバの機能的な実体を使用することでアプローチを集結します… 37 付録A.2。 移動体端末の引き渡しを使用することでアプローチを分散します… 38 付録B.アプリケーションシナリオ… 40 付録B.1。 モバイルIPv6によって可能にされたワイヤレスのLANネットワークにおけるカード操作… 40 付録B.2。 速いモバイルIPv6によって可能にされたネットワークにおけるカード操作… 43
1. Introduction
1. 序論
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-レベル引き渡しを実行するのを可能にします。 仕事は、シームレスのIP引き渡しを許すために移動性プロトコルを広げるために進行中です[Kood03][Malk03]。シームレスのIP移動性プロトコルはモバイルノードを移すことができる候補アクセスルータ(CARs)に関する知識を必要とするでしょう。 CAR発見プロトコルはモバイルノードの次の引き渡しの候補であるアクセスルータの情報の獲得を可能にします。
CAR discovery involves identifying a CAR's IP address and the capabilities that the mobile node might use for a handover decision. There are cases in which a mobile node has a choice of CARs. The mobile node chooses one according to a match between the mobile node's requirements for a handover candidate and the CAR's capabilities. However, the decision algorithm itself is out of the scope of this document.
CAR発見は、モバイルノードが引き渡し決定に使用するかもしれないCARのIPアドレスと能力を特定することを伴います。 モバイルノードがCARsの選択を持っている場合があります。 引き渡し候補とCARの能力のためのモバイルノードの要件の間のマッチに従って、モバイルノードは1つを選びます。 しかしながら、このドキュメントの範囲の外に決定アルゴリズム自体があります。
Liebsch, et al. Experimental [Page 2] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[2ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
The problem statement for CAR discovery is documented in [TKCK02]. In this document, a protocol is described to perform CAR discovery. Section 3 describes two main functions of the CAR discovery protocol. Section 4 describes the core part of the CARD protocol operation. The protocol message format is described in Section 5. Section 6 discusses security considerations, and Section 7 contains a table of protocol parameters. Appendix A contains two alternative techniques for dynamically constructing the CAR table mapping between the access point L2 ID and Access Router IP address, which is necessary for reverse address translation. The default method is static configuration. Appendix B contains two sample scenarios for using CARD.
CAR発見のための問題声明は[TKCK02]に記録されます。 本書では、プロトコルは、CAR発見を実行するために説明されます。 セクション3はCAR発見プロトコルの2つの主な機能について説明します。 セクション4はCARDプロトコル操作のコア一部について説明します。 プロトコルメッセージ・フォーマットはセクション5で説明されます。 セクション6はセキュリティ問題について論じます、そして、セクション7はプロトコルパラメタのテーブルを含みます。 付録AはアクセスポイントL2 IDとAccess Router IPアドレスの間にダイナミックにCARテーブルマッピングを構成するための2つの代替のテクニックを含んでいます。アドレスが逆のアドレス変換に必要です。 デフォルトメソッドは静的な構成です。 付録BはCARDを使用するための2つのサンプルシナリオを含んでいます。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [Brad97].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[Brad97]で説明されるように本書では解釈されることであるべきですか?
This document uses terminology defined in [MaKo03].
このドキュメントは[MaKo03]で定義された用語を使用します。
In addition, the following terms are used:
さらに、次の期間は使用されています:
Access Router (AR)
アクセスルータ(アルゴン)
An IP router residing in an access network and connected to one or
more APs. An AR offers IP connectivity to MNs.
アクセスであるIPルータは、1APsにネットワークでつないで、接続しました。 ARはIPの接続性をMNsに提供します。
Candidate AR (CAR)
候補AR(車)
An AR to which an MN has a choice when performing IP-level
handover.
IP-レベル引き渡しを実行するときミネソタが選択を持っている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が存在であるときに、ミネソタに興味があるかもしれないARによって提供されたサービスの特性は引き渡し候補をみなしました。
L2 ID
L2ID
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アドレスであるかもしれません。
Liebsch, et al. Experimental [Page 3] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[3ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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引き金は以前はよくCARDプロセスを開始していました。 例えば、リンクレイヤスキャンの間、新しいAPのL2 IDを検出するとすぐに、ミネソタはCARDを開始できます。
Access Point (AP)
アクセスポイント(AP)
A wireless access point, identified by a MAC address, providing
service to the wired network for wireless nodes.
有線ネットワークに対するサービスをワイヤレスのノードに提供するMACアドレスによって特定されたワイヤレス・アクセスポイント。
3. CARD Protocol Functions
3. カードプロトコル機能
The CARD protocol accomplishes the following functions.
CARDプロトコルは以下の機能を達成します。
3.1. Reverse Address Translation
3.1. アドレス変換を逆にしてください。
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.
ミネソタがIP-レベル引き渡しに関してCARsに決定する前に新しいAPsのL2IDを聞くことができるなら、メカニズムが逆のアドレス変換に必要です。 CARDプロトコルのこの機能は、ミネソタがAPに接続する関連CARのIPアドレスにAPの容認されたL2 IDを写像するのを可能にします。 CARのIPアドレスを得るために、ミネソタはAPのL2 IDを現在のARに送ります、そして、現在のARは関連CARのIPアドレスをミネソタに提供します。
3.2. Discovery of CAR Capabilities
3.2. 車の能力の発見
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.
CARsの能力に関する情報は最適の引き渡しを決定にするのにミネソタを助けることができます。 この能力情報は目標AR選択アルゴリズムに入力されるように役立ちます。 CARsの能力パラメタのいくつかが静的である場合がありますが、他のものは時間を交換できます。
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で指定されます。
4. CARD Protocol Operation
4. カードプロトコル操作
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
CARDプロトコルで、MNsは関連CARsのIPアドレスに1APsのL2 IDを決議できます。 L2IDは、操作の間、ミネソタによって通常発見されて、潜在的引き渡し候補です。 さらに、CARDはMNsにミネソタの引き渡し決定に影響を及ぼすかもしれない利用可能な帯域幅などのCARsに関連している特定の能力を発見させます。 その上、プロトコルで、ARsはCARsの能力がある地元のCARテーブル(セクション4.1)に居住して、維持します。 これに関しては、CARDプロトコルはCARD RequestとCARD Replyメッセージを利用します。
Liebsch, et al. Experimental [Page 4] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[4ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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).
ミネソタとその現在のAR(セクション5.1.2)と、間に、ミネソタはよく見られます。ARと個人CARs、それぞれ(セクション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.
ミネソタがメッセージがミネソタとその現在のARの間で使用したCARのアドレス、能力情報、CARD Request、およびCARD Replyを検索するのを許容するのがそれぞれ1つ以上のアクセスポイントのL2IDと関連CARsのIPアドレスを含むかもしれません。 また、任意に、CARD ReplyメッセージはCARの能力情報を含むことができます。 CARの能力は属性値組のリストとして指定されます。(組はCapability Containerメッセージパラメタを運ばれます)。
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.
現在のARがCARテーブル(セクション4.1を見る)に応じて回答を返して、RESOLVER ERRORを返す、(.3 .1) 要求を決議できないなら。CARsと関連能力に関する情報は、IP引き渡しの間、目標アクセスルータ選択を実行するのにミネソタによって使用されるかもしれません。セクション5.1を見てください。
The CARD protocol also enables an MN to optionally indicate its preferences on capabilities of interest to its current AR by including the Preferences message parameter in the CARD Request message. The MN's current AR MAY use this information to perform optional capability pre-filtering for optimization purposes, and it returns only these capabilities of interest to the requesting MN. The format of this optional Preferences message parameter is described in Section 5.1.3.2.
また、CARDプロトコルは、ミネソタがCARD RequestメッセージにPreferencesメッセージパラメタを含んでいることによって現在のARに興味がある能力における好みを任意に示すのを可能にします。 ミネソタの現在のAR MAYは最適化目的のために任意の能力プレフィルタリングを実行するのにこの情報を使用します、そして、それは要求ミネソタに興味があるこれらの能力だけを返します。 この任意のPreferencesメッセージパラメタの形式はセクション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.
任意に、ミネソタは能力属性値組のリストを現在のARに提供できます、特定の能力のために能力プレフィルタリングに必要である能力パラメタ(属性)だけではなく、特定の値も示して。 これで、ミネソタの現在のARはCARプレフィルタリングを実行して、能力値が要求ミネソタをミネソタに関する必要条件を満たして戻すCARsのアドレスと能力情報だけを送ります。 この任意のRequirementsメッセージパラメタの形式はセクション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
例えば、任意のPreferencesメッセージパラメタを使用して、ミネソタは、それがIEEE802.11aのインタフェース特有の能力パラメタだけに興味を持っているのを現在のARに示すかもしれません、これがミネソタが実装した唯一のインタフェースであるので。 ミネソタの現在のARはIEEE802.11a特有の能力があるCARsだけを返送します。 同様に、任意のRequirementsメッセージパラメタを使用して、ミネソタは、それが与えられたQoS規制を満たすことができるCARsに興味を持っているだけであるのを現在のARに示すかもしれません。 ここで、ミネソタは、任意のRequirementsメッセージパラメタを使用することでQoS規制価値があるそれぞれのQoS属性を現在のARに送ります。 QoS規制は、属性値組として指示されて、カプセル化されます。
Liebsch, et al. Experimental [Page 5] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[5ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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.
要件メッセージパラメタ。(そのパラメタはミネソタの溯源されたCARD Requestメッセージに追加されます)。 Requirementsメッセージパラメタは、どんな必要なCARsのためにも能力の締切りの値を示すのに使用されるかもしれません。 Preferencesパラメタの属性の受信された任意のリストかRequirementsメッセージパラメタの属性値組のリストによると、ミネソタの現在のAR MAYは、ミネソタに送り返されることである請求されたCARD Replyメッセージの内容について決めるのにこれらのパラメタを使用します。 あるいはまた、ミネソタの現在のARが能力かCARプレフィルタリングに関して最適化を実行しないなら、現在のAR MAYは、CARD Requestメッセージに受け取るように静かに任意のRequirementsとPreferencesメッセージパラメタを無視するのを選びます。
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.
ミネソタはARから共有されて、信じられたアンカーからの証明書に据えつけられる証明経路をさらに、要求できます。 ミネソタはCARD Requestメッセージでミネソタには証明書がある信じられたアンカーのリスト、および証明経路があるAR回答を含めます。 マッチが全く見つけられないなら、ARはCARD Requestから信じられたアンカー名を返します。 ミネソタは現在のARかCARのどちらかのためにチェーンを求めることができます。 信じられたアンカーリストがミネソタの現在のAPのためにAP L2 IDによって伴われるなら、返されたチェーンは現在のARのためのものです。 L2 IDがミネソタがスキャンの間に聞いているAPのためにあって、現在のARに接続されないなら、返されたチェーンはCARのためのものです。 CARD Replyメッセージの系列、ただ一つの証明書を含む各メッセージ、CARD Requestで送られたAPのためのL2識別子、およびCARのためのルータアドレスとしてチェーンを返します(要求があったならAR自身がARになったので)。 チェーンが完全であるときに、ミネソタは、ARの公認されたキーを入手して、その結果、ミネソタと現在のARの間のCARDメッセージと他のメッセージで署名を有効にするのにそれを使用できます。 それに既にキャッシュされたARのための証明経路がないなら、ミネソタだけが信じられたアンカーオプションを送らなければなりません。 ミネソタが前構成、このルータ、または前のルータを通してチェーンを受けたのによるチェーンの前の領収書を通して証明経路をキャッシュさせるなら、信じられたアンカーを送る必要はありません。 セクション6でCARDセキュリティにおける証明書交換とその使用に関する詳しい情報を見つけることができます。
The CARD protocol operation, as described in this section, distinguishes signaling messages exchanged between an MN and its current AR from those exchanged between ARs. Hence, descriptions of signaling messages in the following sections have preceding identifiers referring to the associated interface. Messages that are exchanged between an MN and AR are designated as "MN-AR", and messages between ARs are designated as "AR-AR".
このセクションで説明されるCARDプロトコル操作はミネソタとその現在のARの間でARsの間で交換されたものから交換されたシグナリングメッセージを区別します。 したがって、以下のセクションのシグナリングメッセージの記述には、関連インタフェースについて言及する前の識別子があります。 ミネソタとARの間で交換されるメッセージは「ミネソタ-アルゴン」として指定されます、そして、アルゴンの間のメッセージは「アルゴンアルゴン」として指定されます。
Liebsch, et al. Experimental [Page 6] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[6ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
+--------------+ (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)
+--------------+、(1a)アルゴンアルゴンカード要求+----------+ | 電流|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 車| | アルゴン| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| +--------------+、(2a)アルゴンアルゴンカード回答+----------+ ^ | | | ミネソタ-アルゴンミネソタ-アルゴン| | カード回答(3m)カード要求(2m)対+--------------+ | モバイル| | ノード| <-- カードイニット引き金+--------------+ (1m)
Figure 1: MN-initiated CARD Protocol Overview
図1: ミネソタによって開始されたカードプロトコル概要
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はミネソタ-アルゴンCARD Request/回答プロトコルとアルゴンアルゴンCARD Request/回答プロトコルの操作について説明します。 CARD開始引き金(1m)のアクセスポイントのL2IDか外観を受け取り次第、ミネソタが1を伝えるかもしれませんか、またはミネソタ-アルゴンCARD Requestを使用する現在のARへの、より多くのAP L2IDが(2m)を通信させます。 ミネソタが、ARに逆のアドレス変換に加えて能力発見を実行して欲しいなら、ミネソタ-アルゴンCARD RequestメッセージでC-旗を設定することによって、これを示さなければなりません。 C-旗が設定されないと、CARD Requestメッセージを受け取るARは逆のアドレス変換だけを実行するでしょう。 ミネソタの現在のARは、地方のCARテーブルからの逆のアドレス変換情報(IPアドレス・マッピングへのL2 ID)を使用することで関連CARのIPアドレスにL2 IDを決議するか、またはミネソタがどんなL2 IDメッセージパラメタも添付していないなら、すべてのCARsのIPアドレス情報をただ読みだします。 そして、現在のARは、ミネソタ-アルゴンCARD Replyメッセージ(3m)、どんなCARsのIPアドレス、各CARのCANDIDATEがL2 IDサブオプション状態分野で示されているL2IDのセット、および能力情報が要求されていたときの関連能力も使用することでミネソタに戻ります。
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).
CARがエントリータイムアウトをテーブルの上に置くとき、アルゴンアルゴンCARD Request/回答プロトコルのために、要求しているARはCARD Requestメッセージを同輩に送ります。(1a)。 同輩は求められた情報があるCARD Replyメッセージを返します。(2a)。
4.1. Conceptual Data Structures
4.1. 概念的なデータ構造
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 SHALLは関連CARのIPアドレスに候補APsのL2IDを決議するのに使用されるL2-L3アドレス変換テーブル(CARテーブル)を維持します。 デフォルトで、このアドレス変換テーブルはCARDプロトコル操作のために静的に構成されます。 任意に、CARテーブルはダイナミックに居住されるかもしれません。 2つの可能なアプローチがAppendices A.1とA.2で説明されます。
Liebsch, et al. Experimental [Page 7] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[7ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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 SHOULDは地方のCARテーブルで個々のCARsの能力を保って、維持します、関連能力寿命が考慮に入れられている状態で。 個々の能力エントリーの寿命が期限が切れたなら、それぞれの能力情報をアップデートします。 また、ARはCARテーブルのCARに関連している能力の満了の前に能力交換を起こすかもしれません、その結果、CARテーブルに居住します。 ARのCARテーブルは異なって実装されるかもしれません。 したがって、追加詳細はここに明らかにされません。 ARsはそれらのCARテーブルのそれら自身のAPからARへのマッピングと能力情報を保守しなければなりません、ミネソタがARの証明経路を得ることができるように新たに起動させられたMNsにこの情報を提供するために。
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 SHOULDは、繰り返して同じ情報を要求するのを避けて、引き渡しが差し迫っているときCARsのリストから適切な目標ARをできるだけはやく選択するためにローカルなキャッシュでCARsの発見されたアドレスと能力情報を保守します。
4.2. Mobile Node - Access Router Operation
4.2. モバイルノード--アクセスルータ操作
4.2.1. Mobile Node Operation
4.2.1. モバイルノード手術
To initiate CARD, an MN sends a CARD Request to its current AR, requesting it to resolve the L2 ID of nearby access points to the IP address of associated CARs and also obtain capability parameters associated with these CARs. If the requesting MN wants its current AR to resolve specific L2 IDs, the MN-AR CARD Request MUST contain the CARD protocol-specific L2 ID message parameters. If the MN wants its AR to perform only reverse address translation without appending the CARs' capabilities, the MN refrains from setting the C-flag in the CARD Request message. If the MN wants to perform capability discovery, the MN MUST set the C-flag in the CARD Request message. The CARD Request MAY also contain the Preferences or Requirements message parameter, indicating the MN's preferences on capability attributes of interest or its requirements on CARs' capability attribute-value pairs.
CARD、ミネソタを開始するのは現在のARにCARD Requestを送ります、関連CARsのIPアドレスに近いアクセスポイントのL2 IDを決議して、また、これらのCARsに関連している能力パラメタを得るようそれに要求して。 要求ミネソタが、現在のARに特定のL2IDを決議して欲しいなら、ミネソタ-アルゴンCARD RequestはCARDのプロトコル特有のL2 IDメッセージパラメタを含まなければなりません。 ミネソタが、ARにCARsの能力を追加しないで逆のアドレス変換だけを実行して欲しいなら、ミネソタは、C-旗をCARD Requestメッセージにはめ込むのを控えます。 ミネソタが能力発見を実行したいなら、ミネソタはC-旗をCARD Requestメッセージにはめ込まなければなりません。 また、CARD RequestはPreferencesかRequirementsメッセージパラメタを含むかもしれません、興味がある能力属性におけるミネソタの好みか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.
ミネソタがCARD Requestへのサブオプションの複数のL2 IDを追加するなら、アルゴンは、それぞれのL2 IDが異なったCARに接続するAPに関連していると仮定しなければなりません。 L2ID、アドレス情報、および能力情報が別々のサブオプションで伝えられるので、それぞれのサブオプションはグループを成すパラメタが合わせられるのを許容するためにContext-IDを運びます。 したがって、ミネソタはそれがCARD Requestメッセージに追加するL2 IDサブオプションに異なったContext-ID値を割り当てなければなりません。 いつもL2 IDサブオプションのStatus-コード分野をミネソタのそばのNONE(0×00)に設定しなければなりません。 ミネソタは手当たりしだいに発生している値に一連番号を設定しなければなりません、そして、アルゴンは回答に関するすべてのメッセージで一連番号を含めなければなりません。 回答が複数のメッセージにかかっているなら、各メッセージは同じ一連番号を含んでいます。
Liebsch, et al. Experimental [Page 8] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[8ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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.
対応するミネソタ-アルゴンCARD Replyメッセージを受け取り次第、ミネソタは、CARのアドレスと能力情報を検索するために適切なCARD RequestメッセージでCARD Replyを関連させて、次に、すべてのミネソタ-アルゴンCARD Replyメッセージパラメタを処理します。 ミネソタがどんな以前に送られたCARD RequestメッセージでもCARD Replyを関連させることができないなら、MN SHOULDは静かに回答を捨てます。 CARD Requestメッセージを接続ARに送った後にミネソタがリブートされるとき、これは起こるかもしれません。
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.
CARD ReplyがCARD_REQUEST_RETRY秒以内に受け取られない場合、ミネソタは、CARD Requestを再送するのに指数のbackoffを使用します。 再送されたCARD Requestには、オリジナルと同じ一連番号がなければなりません。 証明経路を除いて。(経路は自然、CARD Replyの情報をただ一つのメッセージに制限するAR SHOULD試みで大きいです)。 それが不可能であるなら、AR MAYは複数のメッセージにおける回答を送ります。 回答に関する最後のメッセージはCARD ReplyオプションでL-旗が、メッセージが関連一連番号のための最終であることを示すようにいつも設定させなければなりません。 CARD Requestに回答を再送するARはいつも完全なCARD Reply系列を送らなければなりません。 Trusted AnchorサブオプションとRouter Certificateサブオプションはミネソタが証明経路で特定の証明書を要求できる手段を提供します、証明経路を運ぶCARD Replyが複数のメッセージにかかっていて、それらの1つが無くなる場合。 しかしながら、初期のCARD Replyに受け取られなかった特定の証明書に関する要求は、ミネソタによる新しい要求として扱わなければならなくて、異なった一連番号を使用しなければなりません。
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.
AddressサブオプションのContext-IDを処理するのに、ミネソタは特定のCARの決心している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パラメタはCARD Replyメッセージに存在しています。 L2 IDパラメタのStatus-コード分野はミネソタに向かって送られた存在の以下の理由の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.
RESOLVER ERROR Status-コード指示: ミネソタの現在のARが特定のL2 IDを決議できないなら、このステータスコードをミネソタに返します。
MATCH Status-Code indication:
If an L2 ID is encountered that shares a CAR with a previously
resolved L2 ID, the AR returns MATCH to the MN. This status code
indicates that the Context-ID of this particular L2 ID sub-option
has been set to the Context-ID of the associated CAR's Address and
Capability Container sub-option, which is sent with this CARD
Reply message. This approach avoids sending the same CAR's
address and capability information multiple times with the same
CARD Reply message in case two or more L2 IDs resolve to the same
MATCH Status-コード指示: 以前に決定しているL2 IDと共に同乗するL2 IDが遭遇するなら、ARはMATCHをミネソタに返します。 このステータスコードは、この特定のL2 IDサブオプションのContext-IDが関連CARのAddressとCapability ContainerサブオプションのContext-IDに設定されたのを示します。(IDはこのCARD Replyメッセージと共に送られます)。 このアプローチは、より多くのケースtwo L2IDにおける同じCARD Replyメッセージがある複数の回が同じくらいに決議する同じCARのアドレスと能力情報を送るのを避けます。
Liebsch, et al. Experimental [Page 9] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[9ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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.
車。 ミネソタは受信されたCARD Replyメッセージの内容から給仕が与えられたAPのCARであることがわかるためにキーとしてのサブオプションのL2 IDに受け取られたContext-IDを使用します。
CANDIDATE Status-Code indication:
If the MN does not append any L2 ID to the CARD Request, the AR
sends back the L2 ID and address information of all CARs. Because
the received parameters' Context-IDs cannot be correlated with an
L2 ID's Context-ID of a previously sent request, the AR chooses
values for the Context-ID and marks these candidate L2 IDs with
CANDIDATE in the status code of the distributed L2 IDs. However,
individual values of L2 IDs' Context-ID allow the MN to assign a
particular L2 ID to the associated Address and the possibly
received Capability Container sub-option.
CANDIDATE Status-コード指示: ミネソタが少しのL2 IDもCARD Requestに追加しないなら、ARはすべてのCARsに関するL2 IDとアドレス情報を返送します。 受信されたパラメタのContext-IDがL2 IDの以前に送られた要求のContext-IDと共に関連できないので、ARはContext-IDに値を選んで、分配されたL2IDのステータスコードでこれらの候補L2IDにCANDIDATEを付けます。 しかしながら、L2IDのContext-IDの個人価値で、ミネソタは関連Addressとことによると容認されたCapability Containerサブオプションに特定の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に、ミネソタが決定するのに、それが初めは起動するCARDを使用できるセクションで説明される、操作は可能です。 また、ミネソタが初めは、それが起動するARのための能力と証明書を決定するのにCARDを使用できますか、またはそれであるならあらかじめ、証明書を入手できません。 これをするために、ミネソタは現在のAP L2 IDと求められた情報があるL2 Identifierオプションを含めます。 ARはそれ自身の情報で返答します。
4.2.2. Current Access Router Operation
4.2.2. 現在のアクセスルータ操作
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.
ミネソタのミネソタ-アルゴンCARD Requestを受け取り次第、接続AR SHALLはどんな関連CARsのIPアドレスにも要求されたAPsのL2 IDを決議します。 ミネソタ-アルゴンCARD Requestメッセージと共にL2 IDパラメタを全く送らないなら、受信ARはすべてのCARsのIPアドレスとC-旗が要求に設定されたときの能力情報を検索します。
In the first case, where the AR resolves only requested L2 IDs, the AR does not send back the L2 ID to the requesting MN. If, however, two or more L2 IDs match the same CAR information, the L2 ID sub- option is sent back to the MN, indicating a MATCH in the Status-Code field of the L2 ID. Furthermore, the AR sets the Context-ID of the returned L2 ID to the value of the resolved CAR's L2 ID, Address, and Capability Container sub-option. If an AR cannot resolve a particular L2 ID, an L2 ID sub-option is sent back to the MN, indicating a RESOLVER ERROR in the L2 ID sub-option's Status-Code field.
前者の場合、AR決議がL2IDを要求しただけであるところに、ARは要求ミネソタへのL2 IDを返送しません。 しかしながら、2か情報、サブオプションが送られる同じより多くのL2IDマッチCAR L2 IDがL2 IDのStatus-コード分野でミネソタ、表示へのMATCHを支持するなら。 その上、ARは決定しているCARのL2 ID、Address、およびCapability Containerサブオプションの値に返されたL2 IDのContext-IDを設定します。 ARが特定のL2 IDを決議できないなら、L2 IDサブオプションはミネソタに送り返されます、L2 IDサブオプションのStatus-コード分野でRESOLVER ERRORを示して。
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
2番目の場合では、すべての候補APsのL2IDをCARD Replyメッセージがある要求ミネソタに送ります。そこでは、ARがCARD Requestと共に少しのL2 IDも受けませんでした。 それをミネソタに示して、ARはCANDIDATEとして個々のL2IDのStatus-コードをマークします。
Liebsch, et al. Experimental [Page 10] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[10ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
associated Context-ID cannot be matched with the ID of a previously sent request.
関連Context-IDを以前に送られた要求のIDに合わせることができません。
In any case, the AR MUST set the Context-ID of the Address and the Capability Container sub-option to the same value as that of the associated L2 ID sub-option.
どのような場合でも、アルゴンは関連L2 IDサブオプションのものと同じ値へのサブオプションのAddressとCapability ContainerのContext-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 MAYは能力かCARsの部分集合を検索します、任意に追加されたPreferencesとRequirementメッセージパラメタを満たして、地方のCARテーブルから。 そして、ミネソタ-アルゴンCARD Replyメッセージを使用することでCARsのアドレス情報と関連能力をミネソタに届けます。 CARsのIPアドレスと能力SHALL、形式に従って、CARDプロトコルメッセージパラメタのためにこの.3通のセクション5.1ドキュメントで定義されるようにコード化されてください。 能力は属性値の組としてコード化されます。(セクション5.1.3で.4に定義された書式によると、組はCapability Containerメッセージパラメタで要約されます)。 応じている現在のAR SHALLはミネソタ-アルゴンCARD Requestにミネソタ-アルゴンCARD Replyに受け取られた一連番号をコピーします。
4.3. Current Access Router - Candidate Access Router Operation
4.3. 現在のアクセスルータ--候補アクセスルータ操作
4.3.1. Current Access Router Operation
4.3.1. 現在のアクセスルータ操作
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.
それがミネソタ-アルゴンCARD Requestを受けるか、またはそれかエントリーの寿命が吐き出そうとしている一層の地方のCARテーブルの能力を検出するとき、ミネソタの現在のAR MAYはCARsとの能力交換を起こします。 AR SHOULDは優先的に直接CARに合図するより要求をむしろ実現させるCARテーブル、およびそれを利用します。SHOULDはCARテーブルがこのために時代について行かせます、ミネソタの応答に不要な遅れを注ぐのを避けるために。
The AR SHOULD issue an AR-AR CARD Request to the respective CARs if complete capability information of a CAR is not available in the current AR's CAR table, or if such information is expired or about to expire. The AR-AR CARD Request message format is defined in Section 5.2.2. The sequence number on the AR-AR interface starts with zero when the AR reboots. The sending AR MUST increment the sequence number in the CARD Request by one each time it sends a CARD Request message.
または、CARの完全な能力情報が現在のARのCARテーブルで利用可能でないか、またはそのような情報が満期であるならAR SHOULDがアルゴンアルゴンCARD RequestをそれぞれのCARsに発行する、吐き出そうとしているために。 アルゴンアルゴンCARD Requestメッセージ・フォーマットはセクション5.2.2で定義されます。 ARがリブートするとき、AR-ARインタフェースの一連番号はゼロから始まります。 CARD Requestメッセージを送るたびに送付アルゴンはCARD Requestで一連番号を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
AR MAYはそれ自身の能力を追加します、リリースされたアルゴンアルゴンCARD Requestに。(能力は、属性値が対にされるのでコード化されて、Capability Containerメッセージパラメタで要約されます)。 アルゴンアルゴンCARD Requestが現在のARの能力をCARに伝えるなら、関連Capability Containerは、どんな値もContext-IDのときに予定されるのを持つことができます、受信CARがこれを処理する必要は全くないとき
Liebsch, et al. Experimental [Page 11] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[11ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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.
L2 IDの不在とAddressサブオプションとして支払われるべきものをさばいてください。 その上、現在のAR MAYはCARDプロトコルメッセージ便乗を実行するそれ自身の能力に関してCARに知らせるためにはサブオプションのCapability ContainerにP-旗をはめ込みます。
Optionally, a current AR MAY append the Preferences sub-option to the AR-AR CARD Request to obtain only capability parameters of interest from a CAR.
任意に、現在のAR MAYは、CARから興味がある能力パラメタだけを得るためにアルゴンアルゴンCARD RequestへのサブオプションのPreferencesを追加します。
Upon receipt of the AR-AR CARD Reply, sent by the CAR in response to the previously sent request, the MN's current AR SHALL extract the capability information from the payload of the received message and store the received capabilities in its local CAR table. The lifetime of individual capabilities is to be set according to the lifetime indicated for each capability received. The values of the table entries' timeouts shall depend upon the nature of individual capabilities.
以前に送られた要求に対応してCARによって送られたアルゴンアルゴンCARD Replyを受け取り次第、ミネソタの現在のAR SHALLは受信されたメッセージのペイロードから能力情報を抜粋して、地方のCARテーブルに容認された能力を格納します。 個々の能力の寿命は受け取られた各能力のために示された生涯に従って設定されることです。 テーブル項目のタイムアウトの値は個々の能力の本質に依存するものとします。
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か能力の構成がダイナミックに変化するなら、CARsは求められていないCARD Replyメッセージをグローバルに隣接しているARsに送ることができます。 現在のARがエントリーが地方のCARテーブルにあるCARから求められていないCARD Replyメッセージを受け取るなら、現在のARは、以前に受信された求められていないCARD Replyメッセージのものと比べて、容認されたCARD Replyの一連番号が増加したのをチェックします。同じCARからメッセージを送ります。 そして、容認された能力に従って、現在のARは地方のCARテーブルをアップデートできます。 新しいCARが加えられるなら、ARはCARテーブルにないCAR、または、リブートしたCARからCARD Replyを受けるかもしれません。 この場合、一連番号は0です。 ARsがIPsecセキュリティ協会を共有するというセクション6で詳細な要件は、ARが非認証されたソースからCARD情報を決して受け入れないのを確実にします。
4.3.2. Candidate Access Router Operation
4.3.2. 候補アクセスルータ操作
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
アルゴンアルゴンCARD Requestを受け取り次第、CARは発信しているARの能力を抽出するものとします、発信しているARが能力を含んでいたなら。 CAR SHALLは適切にCARテーブルに容認された能力を格納して、個々の能力にタイマを設定します。 テーブル項目のタイムアウトの値はアルゴンアルゴンCARD Replyメッセージの能力の本質に依存します。 それがアルゴンアルゴンCARD Request Messageで受信されたので、CARはアルゴンアルゴンCARD Reply Messageに同じ一連番号を含まなければなりません。 属性値のリストがCapability Containerメッセージパラメタで対にされるとき、アルゴンアルゴンCARD ReplyはCARの能力を含んでいるものとします。 発信しているARが任意のPreferencesサブオプションを追加したなら、CAR MAYは要求しているARに興味があって、特定されていた状態で能力フィルタリングを実行して、それらの能力だけを返送します。
Liebsch, et al. Experimental [Page 12] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[12ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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.
好みのサブオプション。 アルゴンアルゴンCARD Replyが以前に容認されたアルゴンアルゴンCARD Requestに基づいているので、CAR MUSTはアルゴンアルゴンCARD Replyの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つかまだ変化しているなら、CAR MAYは求められていないCARD Replyメッセージをグローバルに隣接しているARsに送ります。 それぞれの求められていないCARD Replyメッセージで、送付先アドレスとして隣接ARのユニキャストアドレスを持つべきであり、U-旗を設定しなければなりません。 連続した求められていないCARD Replyメッセージで、ARブーツであるときに、0から始まって、それに従って、一連番号を増加しなければなりません。
4.4. CARD Protocol Message Piggybacking on the MN-AR Interface
4.4. ミネソタ-ARインタフェースで便乗するカードプロトコルメッセージ
CARD supports another mode of CAR information distribution, in which the capabilities are piggybacked on fast handover protocol messages. To allow MNs and ARs appending the ICMP-option type CARD Request and CARD Reply (Section 5.1.2) to the ICMP-type Fast Mobile IPv6 [Kood03] signaling messages, the MN and AR should know about the signaling peer's capability for CARD protocol message piggybacking. This requires dynamic discovery of piggybacking capability using the P-flag in the MN-AR CARD Request and the MN-AR CARD Reply message, as well as in the Capability Container message parameter. The format of these messages and parameters is described in Section 5.1.
CARDはCAR情報流通の別の方法を支持します。(そこでは、能力が速い引き渡しプロトコルメッセージで背負われます)。 ICMP-オプションを追加するMNsとARsを許容するために、メッセージに合図しながら、ICMP-タイプのFastのモバイルIPv6[Kood03]にCARD RequestとCARD Reply(セクション5.1.2)をタイプしてください、とミネソタとARはCARDプロトコルメッセージ便乗でシグナリング同輩の能力に関して知っているはずです。 これは、ミネソタ-アルゴンCARD Requestとミネソタ-アルゴンCARD Replyメッセージ、およびCapability ContainerメッセージパラメタでP-旗を使用することで便乗能力のダイナミックな発見を必要とします。 これらのメッセージとパラメタの形式はセクション5.1で説明されます。
The MN sends the very first CARD Request to its current AR using the ICMP-type CARD main header for transport, as described in Section 4.2.1. If the MN supports CARD-protocol message piggybacking, the P-flag in this very first CARD Request message is set. On receipt of the CARD Request message, the current AR learns about the MN's piggybacking capability. To indicate its piggybacking capability, the AR sets the P-flag in the CARD Reply message. If the AR does not support piggybacking, all subsequent CARD-protocol messages between the MN and the AR are sent stand-alone, using the CARD main header. If both nodes (the MN and its current AR) support CARD-protocol message piggybacking, subsequent CARD protocol messages can be conveyed as an option via the Fast Mobile IPv6 Router Solicitation for Proxy (RtSolPr) and Proxy Router Advertisement (PrRtAdv) messages. During the CARD process, an MN learns about CARs' piggybacking capability at the discovery phase, as the Capability Container (described in Section 5.1.3.4) also carries a P-flag. This allows the MN to perform CARD protocol message piggybacking immediately after a handover to a selected CAR, assuming that this CAR supports CARD protocol piggybacking.
ミネソタは輸送のために現在のAR使用へのICMP-タイプの最初のCARD Request CARD非常に主なヘッダーを送ります、セクション4.2.1で説明されるように。 ミネソタがCARD-プロトコルメッセージ便乗を支持するなら、このまさしくその最初のCARD RequestメッセージのP-旗は設定されます。 CARD Requestメッセージを受け取り次第、現在のARはミネソタの便乗能力に関して学びます。 便乗能力を示すために、ARはP-旗をCARD Replyメッセージにはめ込みます。 ARが、便乗するのを支持しないなら、スタンドアロンの状態でミネソタとARの間のすべてのその後のCARD-プロトコルメッセージを送ります、CARDの主なヘッダーを使用して。 両方のノード(ミネソタとその現在のAR)がCARD-プロトコルメッセージ便乗を支えるなら、オプションとしてProxy(RtSolPr)とProxy Router Advertisement(PrRtAdv)メッセージのためのFastのモバイルIPv6 Router Solicitationを通してその後のCARDプロトコルメッセージを伝えることができます。 CARDの過程の間、ミネソタはCARsの便乗能力に関して発見フェーズで学びます、また、Capability Container(セクション5.1.3では、.4について説明する)がP-旗を運ぶとき。 これで、ミネソタは引き渡し直後選択されたCARに便乗するCARDプロトコルメッセージを実行できます、このCARがCARDプロトコル便乗を支持すると仮定して。
If a MN prefers the reverse address translation function of the Fast Mobile IPv6 protocol, it can use CARD protocol message piggybacking to retrieve only the CARs' capability information. To indicate that
ミネソタがFastのモバイルIPv6プロトコルの逆のアドレス変換機能を好むなら、それは、CARsの能力情報だけを検索するのにCARDプロトコルメッセージ便乗を使用できます。 それを示すために
Liebsch, et al. Experimental [Page 13] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[13ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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.
逆のアドレス変換は必要でなく、便乗しているCARD RequestメッセージはA-旗を設定しなければなりません。 これで、現在のARはCapability Containerサブオプションだけを追加します。 Capability Containerを関連づけるのはインデックスとして適切なCAR、個々のCapability ContainerのContext-IDへのIPアドレスへのCARD Replyメッセージのパラメタを使用しなければならないので、発信しました、PrRtAdvメッセージオプションにおける関連IPアドレスを示して。 個々のCapability ContainersのContext-IDはミネソタの現在のARによって適切に設定されます。 Context-IDがPrRtAdvメッセージの特定のIPアドレスオプションに関連づけることができるのを評価する個人がこのドキュメントの範囲の外にどういるかに関する詳細。
5. Protocol Messages
5. プロトコルメッセージ
5.1. CARD Messages for the Mobile Node-Access Router Interface
5.1. モバイルノードアクセスルータインタフェースへのカードメッセージ
5.1.1. MN-AR Transport
5.1.1. ミネソタ-AR輸送
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.
ミネソタ-ARインタフェースは輸送にICMPを使用します。 ICMPメッセージが単一のパケットに制限されて、ICMPがシグナリングが無くなるならパケットを再送するために条項を全く含んでいないので、CARDプロトコルはミネソタ-ARインタフェースに関する輸送性能を向上させるための条項を取り入れます。 MNs SHOULDは単一のICMPパケットで要求された情報量を制限します、IPレベルを超えて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).
ICMP-タイプのFastのモバイルIPv6[Kood03]を通してCARDプロトコルメッセージを伝えることができないとき、MNsとARsはExperimental ICMP-タイプの主なヘッダー[Ke04]を使用します。 ミネソタ-ARインタフェースは実行されなければなりません、そして、SHOULDは輸送にCARD ICMP-タイプヘッダーを使用します。 利用可能であるなら、ミネソタ-ARインタフェースは輸送(セクション4.4)に、ICMP-タイプのFastのモバイルIPv6[Kood03]を使用するかもしれません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+- - - -
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+-+-+-+-+-+-+-+- - - -
IP Fields:
IP分野:
Source Address:
An IP address assigned to the sending interface.
ソースアドレス: 送付インタフェースに割り当てられたIPアドレス。
Liebsch, et al. Experimental [Page 14] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[14ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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]).
以下をタイプしてください。 実験的なMobilityはタイプします(IPv4とIPv6のためにIANAによって割り当てられて、[Ke04]を見てください)。
Code: 0
コード: 0
Checksum: The ICMP checksum.
チェックサム: ICMPチェックサム。
Subtype: Experimental Mobility subtype for CARD; see [Ke04].
Subtype: CARDのための実験的なMobility subtype。 [Ke04]を見てください。
Reserved: This field is currently unused. It MUST be
initialized to zero by the sender and MUST be
ignored by the receiver.
予約される: この分野は現在、未使用です。 それを送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Valid Options:
妥当な選択肢:
CARD Request: The CARD Request allows entities to request CARD-
specific information from ARs. To support
processing of the CARD Request message on the
receiver side, further sub-options may be carried,
serving as input to the reverse address translation
function and/or capability discovery function.
カード要求: CARD Requestは実体にARsからCARD特殊情報を要求させます。 受信機側の上のCARD Requestメッセージであり処理するのを支持するために、さらなるサブオプションは運ばれるかもしれません、逆のアドレス変換機能、そして/または、能力発見機能に入力されるように役立って。
CARD Reply: The CARD Reply carries parameters, previously
requested with a CARD Request, back to the sender
of the CARD Request.
カード回答: CARD Replyは以前にCARD Requestと共に要求されたパラメタを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.
層-2ID(義務的な): Layer-2IDサブオプション、[5.1 .3 .1は]決議されるIPアドレスと能力情報がことであるCARに関連しているアクセスポイントのLayer-2アドレスと同様にアクセスポイントのタイプの情報を運びます。
Liebsch, et al. Experimental [Page 15] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[15ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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.
能力容器(義務的な): Capability Containerサブオプションは独身のCARの能力の情報を運びます。 このサブオプションの形式はセクション5.1.3で.4に説明されます。
Address (mandatory):
The Address sub-option carries information on an
individual CAR's resolved IP address. The format
of the Address sub-option is described in Section
5.1.3.5.
アドレス(義務的な): Addressサブオプションは個々のCARの決心しているIPアドレスの情報を運びます。 Addressサブオプションの形式はセクション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.
アンカー(義務的な)は信じました: Trusted Anchorサブオプションはミネソタには証明書がある信じられたアンカーの名前を運びます。 Trusted Anchorサブオプションの形式はセクション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.
ルータ証明書(義務的な): Router Certificateサブオプションは現在のARかCARのために経路で1通の証明書を運びます。 チェーンはARがミネソタと共用して共有する信じられたアンカーで始動する証明書を含めます、ルータ自体に。 Router Certificateサブオプションの形式はセクション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.
好み(任意の): Preferencesサブオプションは要求実体に興味がある属性の情報を運びます。 AVP符号化規則によると、属性はコード化されます。(それは、セクション5.1.4で説明されます)。 AVP CodeとData分野の適切な設定に、.2にセクション5.1.3を見てください。 任意の能力プレフィルタリングがARsに実行される場合にだけ、このサブオプションは使用されています、そして、それは要求ミネソタに興味がある能力だけを提供します。
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-
要件(任意の): Requirementsサブオプションはミネソタの現在のARの上のCARsのプレフィルタリングに必要である属性値組の情報を運びます。 このパラメタは、ミネソタの現在のARが興味があるCARsの唯一の情報を要求ミネソタに送り返すのを許容するためにミネソタ特定の属性値組を運びます。 自分の能力パラメタと与えられた方針か敷居に従って、CARsはARsでフィルターにかけられます、Requirementsでコード化されるようにサブ
Liebsch, et al. Experimental [Page 16] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[16ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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.
オプション。 AVP符号化規則によると、属性値組はコード化されます。(それは、セクション5.1.4で説明されます)。 規則はセクション5.1.3で.3にRequirementsサブオプションのためのAVP CodeとData分野の適切な設定に説明されます。
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 Requestsが再送されます。 初期の「再-トランスミッション」はCARD_REQUEST_RETRY待ちの期間の後に現れます。 指数関数的に増加する待ち間隔でRetransmissionsを作らなければなりません(その都度待ちを倍にして)。 応答(誤りであるかもしれない)を得たか、またはCARD_RETRY_MAX秒が起こるまで、CARD Requestsは再送されるべきです。 ARsはCARD_RETRY_MAX秒以降同じ一連番号を持っているどんなCARD Requestsも捨てなければなりません。 CARD Replyが複数のICMPメッセージにかかっているなら、各メッセージで同じ一連番号を使用しなければなりません。
MNs that retransmit a CARD Request use the same CARD sequence number. This allows the AR to cache its reply to the original request and then to send it again, should a duplicate request arrive. This cached information should only be held for a maximum of CARD_RETRY_MAX seconds after receipt of the request. Sequence numbers SHOULD be chosen randomly. Random sequence numbers avoid duplicates if MNs restart frequently and simplify sequence-number maintenance on both the MN and AR when MNs frequently appear and disappear due to movement between CARs.
CARD Requestを再送するMNsが同じCARD一連番号を使用します。 これで、ARはオリジナルの要求に回答をキャッシュして、そして、再びそれを送ります、写し要求が到着するなら。 このキャッシュされた情報は要求の領収書のRETRY_MAX秒後に最大CARD_のために保持されるだけであるべきです。 一連番号SHOULD、手当たりしだいに選ばれてください。 MNsがCARsの間の動きのため頻繁に見え隠れすると、MNsがミネソタとARの両方で頻繁に再開して、一連番号維持を簡素化するなら、ランダム・シーケンス番号は写しを避けます。
5.1.2. CARD Options Format
5.1.2. カードオプション形式
All options are of the following form:
すべてのオプションが以下のフォームのものです:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Vers.| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ|Vers| … | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
分野:
Type: 8-bit identifier of the type of option, assigned by
IANA. See [Ke04] for CARD Request and CARD Reply
values.
以下をタイプしてください。 IANAによって割り当てられたオプションのタイプの8ビットの識別子。 CARD RequestとCARD Reply値に関して[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は無効です。
Liebsch, et al. Experimental [Page 17] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[17ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
Vers.: 3-bit version code. For this specification,
Vers.=1.
Vers、: 3ビットのバージョンコード。 この仕様、Vers.=1であるときに。
5.1.2.1. CARD Request Option
5.1.2.1. カード要求オプション
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Vers.|P|C|A|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ|Vers| P|C|A|T| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブオプション+++++++++++++++--、--、-
Fields:
分野:
Type: Assigned by IANA for IPv4 and IPv6; see [Ke04].
以下をタイプしてください。 IPv4とIPv6のためにIANAによって割り当てられます。 [Ke04]を見てください。
Length: The length of the option in units of 8 octets, including
the type and length fields as well as sub-options.
長さ: サブオプションと同様にタイプと長さの分野を含む8つの八重奏のユニットのオプションの長さ。
Vers.: 3-bit version code. For this specification, Vers.=1.
Vers、: 3ビットのバージョンコード。 この仕様、Vers.=1であるときに。
Flags: P-flag: Indicates the CARD-protocol message
piggybacking capability of the CARD
Request message sender. A description
for proper use of this flag can be
found in Section 4.4 of this document.
旗: P-旗: CARD Requestメッセージ送付者のCARD-プロトコルメッセージ便乗能力を示します。 このドキュメントのセクション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-旗: また、要求実体が関連CARsの能力に興味を持っているのを示します。 ミネソタが、ARにアドレス情報に加えてCARsの能力パラメタをCARD Replyに追加して欲しいなら、ミネソタはこの旗を設定しなければなりません。
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.
1旗: 要求実体が逆のアドレス変換を実行するこのメッセージの受信機を必要としないのを示します。 CARDプロトコルメッセージが逆のアドレス変換を実行するプロトコルで背負われるなら、この旗は設定されます。 詳細について、このドキュメントのセクション4.4を参照してください。
Liebsch, et al. Experimental [Page 18] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[18ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
T-flag: Indicates that the requesting entity is
interested in obtaining all
certificates from the responder. This
flag is only valid on the AR-AR
interface.
T-旗: 要求実体が応答者からすべての証明書を入手したがっているのを示します。 この旗は単にAR-ARインタフェースで有効です。
The flag combination A=1 and C=0 is invalid, and the flag
T=1 is invalid on the MN-AR interface. The AR MUST
discard an invalid message and log an appropriate error
message.
旗の組み合わせA=1とC=0は無効です、そして、旗のT=1はミネソタ-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サブオプション--好みのサブオプション--要件サブオプション--信じられたAnchorサブオプション
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ビットの境界整列要求を満たさなければなりません。 これは、全体のCARD Requestオプションが8n整列規制を満たすのを確実にするでしょう。
5.1.2.2. CARD Reply Option
5.1.2.2. カード回答オプション
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Vers.|P|U|L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ|Vers| P|U|L| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブオプション+++++++++++++++--、--、-
Fields:
分野:
Type: Assigned by IANA for IPv4 and IPv6 [Ke04].
以下をタイプしてください。 IPv4とIPv6[Ke04]のためにIANAによって割り当てられます。
Length: The length of the option in units of 8 octets, including
the type and length fields as well as sub-options.
長さ: サブオプションと同様にタイプと長さの分野を含む8つの八重奏のユニットのオプションの長さ。
Liebsch, et al. Experimental [Page 19] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[19ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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-旗: CARD Replyメッセージ送付者のCARD-プロトコルメッセージ便乗能力を示します。 このドキュメントのセクション4.4でこの旗の適切な使用のための記述を見つけることができます。
U-flag: Indicates an unsolicited CARD Reply.
This flag is only valid on the AR-AR
interface.
U-旗: 求められていないCARD Replyを示します。 この旗は単に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-旗: このメッセージが複数のICMPメッセージ回答で最後のメッセージであるなら、セットしてください。 この旗は単にミネソタ-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-ミネソタメッセージの旗の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サブオプション--能力Containerサブオプション--アドレスサブオプション--ルータCertificateサブオプション
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ビットの境界整列要求を満たさなければなりません。 これは、全体のCARD Requestオプションが8n整列規制を満たすのを確実にするでしょう。
5.1.3. Sub-Options Format
5.1.3. サブオプション形式
All sub-options are of the following form:
すべてのサブオプションが以下のフォームのものです:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Sub-Option Data . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |サブオプションタイプ|サブOptionレン| サブオプションデータ…+++++++++++++++++++++++++++++++++
Liebsch, et al. Experimental [Page 20] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[20ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
Sub-Option Type: 8-bit identifier of the type of option. The
sub-options defined in this document are listed
in the table below. The table also indicates
on which interfaces the sub-option is valid.
サブオプションタイプ: オプションのタイプの8ビットの識別子。 本書では定義されたサブオプションは以下のテーブルに記載されています。 また、テーブルは、サブオプションがどのインタフェースで有効であるかを示します。
Description Type Interface
| | / \
| | MN-AR AR-AR
---------------------------------------------------------------
L2 ID 0x01 x
Address 0x02 x
Capability Container 0x03 x x
Preferences 0x04 x x
Requirements 0x05 x
Trusted Anchor 0x06 x
Router Certificate 0x07 x x
記述タイプインタフェース| | / \ | | ミネソタ-アルゴンアルゴンアルゴン--------------------------------------------------------------- L2 ID0x01x Address0x02x Capability Container0x03x x Preferences0x04x x Requirements0x05x Trusted Anchor0x06x Router Certificate0x07x 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つの八重奏のユニットにあります。 より短いサブオプションはヌル八重奏で水増しされます。 詰め物の範囲はサブオプションコンテンツによって測定されます。
5.1.3.1. L2 ID Sub-Option
5.1.3.1. L2IDサブオプション
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Context-ID | Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-Type | L2 ID . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |サブオプションタイプ|サブOptionレン| Context ID| ステータスコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2-タイプ| L2ID(+++++++++++++++++++)--、-
Sub-Option Type:
0x01
サブオプションタイプ: 0×01
Sub-Option Length:
Length of the sub-option.
サブオプションの長さ: サブオプションの長さ。
Context-ID: Associates the L2 ID, IP address and other parameters
that belong to the same AR IP address but are encoded
in separate sub-options.
Context ID: 同じAR IPアドレスに属すL2 ID、IPアドレス、および他のパラメタを関連づけますが、別々のサブオプションでは、コード化されます。
Liebsch, et al. Experimental [Page 21] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[21ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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.
ステータスコード: この分野は、特定のL2 IDのために結果を処理しながら要求実体の受け取ったことを知らせるためにARsを許容します。 CARD Replyメッセージで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.
0×00: NONE--L2 IDがCARD Requestに含まれているとき、この値を設定しなければなりません。
0x01: CANDIDATE - MUST be set in a CARD Reply when a
L2 ID sub-option is included with information
about candidate APs' L2 IDs. Candidate L2 IDs
are sent if the CARD Request did not include a
specific L2 ID for resolution. If CANDIDATE is
set, the AR MUST set the Context-ID field of
individual parameters to a value that allows
associated L2 ID, address, and capability
information to be matched on the receiver side.
0×01: CANDIDATE--L2 IDサブオプションが候補APsのL2IDの情報で含まれているとき、CARD Replyに設定しなければなりません。 CARD Requestが解決のための特定のL2 IDを含んでいなかったなら、候補L2IDを送ります。 CANDIDATEが用意ができているなら、アルゴンは、関連L2 ID、アドレス、および能力情報を許容する値への個々のパラメタのContext-ID分野に受信機側で合わせられるように設定しなければなりません。
0x02: MATCH - MUST be set in the CARD Reply to
identify that this L2 ID matches previously
resolved CAR information for a different L2 ID.
If MATCH is set, the AR sets the Context-ID in
the L2-ID sub-option to identify the matching
previously resolved L2 ID.
0×02: MATCH--CARD ReplyにこのL2 IDが以前に合っているのを特定するように設定しなければならないのが異なったL2 IDのためのCAR情報を決議しました。 MATCHが用意ができているなら、ARは合っている以前に決定しているL2 IDを特定するためにはサブオプションのL2-IDにContext-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.
0×03: RESOLVER ERROR--L2 IDを決議できないなら、CARD Replyに設定しなければなりません。 ARは返されたL2 IDサブオプションにStatus Codeのためのこの値をはめ込みます。
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.
L2ID: 個々のCARのアクセスポイントに関する可変長Layer-2識別子。 詰め物のない長さはL2タイプによって測定されます。
5.1.3.2. Preferences Sub-Option
5.1.3.2. 好みのサブオプション
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Preferences
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |サブオプションタイプ|サブOptionレン| 好みの+++++++++++++++++++++++++++++++++
Liebsch, et al. Experimental [Page 22] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[22ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
Sub-Option Type:
0x04
サブオプションタイプ: 0×04
Sub-Option Length:
Length of the sub-option.
サブオプションの長さ: サブオプションの長さ。
Preferences: List of capability attribute values (see Section
5.1.4).
好み: 能力属性値(セクション5.1.4を見る)のリスト。
Only ATTRIBUTE (AVP Code; see Section 5.1.4) fields MUST be present and set for individual capabilities, which are of interest to the requesting entity. The LIFETIME and VALUE (Data) indicator will not be processed and can be omitted. The AVP LENGTH indicator is also not present, as the preferences are indicated only with a list of 16-bit encoded ATTRIBUTE fields. If 64-bit boundary alignment requirements cannot be met with the list of ATTRIBUTE values, padding the missing 16-bit MUST be done with an ATTRIBUTE value of 0x0000. An ATTRIBUTE code of 0x0 is reserved so that the end of the ATTRIBUTE code list can be determined when an ATTRIBUTE value of 0x0 is read.
ATTRIBUTE(AVP Code; セクション5.1.4を見る)分野だけが、存在していて、個々の能力のためにセットしなければなりません。(能力は要求実体に興味があります)。 LIFETIMEとVALUE(データ)インディケータを処理しないで、省略できます。 また、AVP LENGTHインディケータも存在していません、好みが単に16ビットのコード化されたATTRIBUTE分野のリストで示されるように。 ATTRIBUTE値のリストで64ビットの境界整列要求を満たすことができないなら、0×0000のATTRIBUTE値でなくなった16ビットを水増ししなければなりません。 0×0のATTRIBUTEコードは、0×0のATTRIBUTE値が読まれるとき、ATTRIBUTEコードリストの終わりが決定するように、予約されています。
The use of the Preferences sub-option is optional and is for optimization purposes.
Preferencesサブオプションの使用は、任意であり、最適化目的のためのものです。
5.1.3.3. Requirements Sub-Option
5.1.3.3. 要件サブオプション
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |サブオプションタイプ|サブOptionレン| 要件+++++++++++++++++++++++++++++++++
Sub-Option Type:
0x05
サブオプションタイプ: 0×05
Sub-Option Length:
Length of the sub-option.
サブオプションの長さ: サブオプションの長さ。
Requirements: AVP-encoded requirements (see Section 5.1.4)
要件: AVPによってコード化された要件(セクション5.1.4を見ます)
AVPs MUST be encoded according to the rule described in Section 5.1.4. Both the ATTRIBUTE (AVP Code) and VALUE (Data) fields MUST be present and set appropriately. The end of the Requirements list can be determined when an ATTRIBUTE value of 0x0 is read.
セクション5.1.4で説明された規則に従って、AVPsをコード化しなければなりません。 両方のATTRIBUTE(AVP Code)とVALUE(データ)分野は、適切に存在していて、セットしなければなりません。 Requirementsリストの終わりはATTRIBUTEであるときに、決定して、0×0の値が読まれるということであるかもしれません。
The use of the Requirements sub-option is optional and is for optimization purposes.
Requirementsサブオプションの使用は、任意であり、最適化目的のためのものです。
Liebsch, et al. Experimental [Page 23] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[23ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
5.1.3.4. Capability Container Sub-Option
5.1.3.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 |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVPs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |サブオプションタイプ|サブOptionレン| Context ID|P| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs+++++++++++++++--、--、-
Sub-Option Type:
0x03
サブオプションタイプ: 0×03
Sub-Option Length:
Length of the sub-option.
サブオプションの長さ: サブオプションの長さ。
Context-ID: Associates the L2 ID, IP address, and other parameters
that belong to the same AR IP address but are encoded
in separate sub-options.
Context ID: 同じAR IPアドレスに属すL2 ID、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-旗: 能力がこのCapability Containerで伝えられるCARの便乗能力を示します。 この旗で、ミネソタは、CARDプロセスの後に選択された新しい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: AVPsは能力がCARDプロトコルにおいて、関連している情報であるとカプセル化するメソッドです。 AVP符号化規則とリスト構文解析に関してセクション5.1.4を見てください。
5.1.3.5. Address Sub-Option
5.1.3.5. アドレスサブオプション
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Context-ID | Address Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |サブオプションタイプ|サブOptionレン| Context ID| アドレスタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス+…++++++++++++++++、-、--、--、--、-
Sub-Option Type:
0x02
サブオプションタイプ: 0×02
Liebsch, et al. Experimental [Page 24] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[24ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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.
Context ID: 同じAR IPアドレスに属すL2 ID、IPアドレス、および他のパラメタを関連づけますが、別々のサブオプションでは、コード化されます。
Address Type: Indicates the type of the address.
タイプに演説してください: アドレスのタイプを示します。
0x01 IPv4
0x02 IPv6
0×01 IPv4 0x02IPv6
Address: The Candidate Access Router's IP address.
アドレス: Candidate Access RouterのIPアドレス。
5.1.3.6. Trusted Anchor Sub-Option
5.1.3.6. 信じられたアンカーサブオプション
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trusted Anchor Name
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |サブオプションタイプ|サブOptionレン| コンポーネント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アンカー名+++++++++++++++++を信じる、-、--、--、--、-
Sub-Option Type:
0x06
サブオプションタイプ: 0×06
Sub-Option Length:
Length of the sub-option.
サブオプションの長さ: サブオプションの長さ。
Reserved: Initialized to zero, ignored on receipt.
予約される: ゼロに初期化されて、領収書の上で無視されています。
Component: A 2 octet unsigned integer field set to 65,535 if the
sender desires to retrieve all the certificates in the
certification path. Otherwise, it is set to the
component identifier corresponding to the certificate
that the receiver wants to retrieve.
コンポーネント: 送付者が、証明経路ですべての証明書を検索することを望んでいるなら、2八重奏符号のない整数分野は6万5535にセットしました。 さもなければ、それは受信機が検索したがっている証明書に対応するコンポーネント識別子に設定されます。
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).
信じられたアンカー名: 証明経路コンポーネント(証明経路コンポーネント名前コード化に関するその他の詳細に関して[Arkko04]を見る)のX.501名のためのDERコード化。
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.
Trusted Anchorサブオプションを含むCARD Requestメッセージはいかなる他のサブオプションも含んではいけません、興味があるAPを特定するただ一つのL2 IDサブオプションを除いて。
Liebsch, et al. Experimental [Page 25] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[25ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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.
アンカーサブオプションSHOULDがCARD_REQUEST_RETRY秒以内に受け取られなかった個々のコンポーネントのために全体のリストに関する要求を再送するよりむしろ再送されると信じました。 その後のretransmissions SHOULDはどんな容認されたオプションも考慮に入れて、受け取られていないものを要求するだけです。
5.1.3.7. Router Certificate Sub-Option
5.1.3.7. ルータ証明書サブオプション
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Context-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All Components | Component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Certificate... |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |サブオプションタイプ|サブOptionレン| Context ID| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | すべてのコンポーネント| コンポーネント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | 証明します。 | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | そっと歩きます… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type:
0x07
サブオプションタイプ: 0×07
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.
Context ID: 同じAR IPアドレスに属すL2 ID、IPアドレス、および他のパラメタを関連づけますが、別々のサブオプションでは、コード化されます。
Reserved: Initialized to zero, ignored on receipt.
予約される: ゼロに初期化されて、領収書の上で無視されています。
All Components:
2 octet unsigned integer giving the total number of
certificates in the certification path.
すべてのコンポーネント: 2 合計が付番する証明経路の証明書の八重奏符号のない整数付与。
Component: 2 octet unsigned integer giving the location of this
certificate in the certification path.
コンポーネント: 2 この位置が証明経路で証明する八重奏符号のない整数付与。
Certificate: Variable-length field containing the X.509v3 router
certificate encoded in ASN.1 (see [Arkko04] for more
detail on a certificate profile that includes
encoding).
以下を証明してください。 X.509v3ルータ証明書がASN.1(コード化するのを含んでいる証明書プロフィールに関するその他の詳細に関して[Arkko04]を見ます)でコード化した可変長の分野含有。
Liebsch, et al. Experimental [Page 26] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[26ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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.
詰め物: オプションの長さをLength分野のそばの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.
Router Certificateサブオプションを含むCARD Replyはそのようなオプションの、よりサブ1つ以上を含んではいけません、そして、CARD ReplyはContext-ID分野があるチェーンを所有しているルータのためのサブオプションのAddressが非ゼロ値、および他のサブオプションなしで設定する合っているL2 IDサブオプションとルータを含まなければなりません。 CARD Reply SHOULDにいかなる他のサブオプションも含んでいて、無視されてください。 回答が複数のICMPメッセージにかかっているなら、送られた最初のメッセージでL2 IDサブオプションとルータAddressサブオプションを含めなければなりません、そして、すべてのメッセージのサブオプションのRouter CertificateのContext-ID分野をL2 IDのそれと同じ値とAddressサブオプションに設定しなければなりません。 AR SHOULDが経路の信頼アンカー直後証明書が最初の証明書であるように返された証明経路を注文する返答は発信しました、即座の検証を許すために。 信頼アンカーはSHOULD NOT自身を証明します。送ります。
5.1.4. Capability AVP Encoding Rule
5.1.4. 能力AVP符号化規則
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code | AVP Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Lifetime | Data . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPコード| AVPの長さ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生涯を結果と考えてください。| データ(+++++++++++++++++++++++++++++)--、-
AVP Code: Identifies the attribute uniquely. The AVP Code
0x0000 is reserved and MUST NOT be assigned to a
capability.
AVPコード: 唯一属性を特定します。 AVP Code0x0000は予約されていて、能力に割り当てられてはいけません。
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 Code、AVP Length、Reserved、Lifetime、およびData分野を含んでいて。
Reserved: Initialized to zero, ignored on receipt.
予約される: ゼロに初期化されて、領収書の上で無視されています。
Lifetime: Specifies the lifetime of the encoded capability in
seconds. In the case of a static capability, the
Lifetime field MUST be set to the maximum value
(0xffff), which indicates that the lifetime of this
capability parameter never expires. A lifetime value
of 0x0000 deletes a capability entry.
生涯: 秒にコード化された能力の生涯を指定します。 静的な能力の場合では、最大値(0xffff)にLifetime分野を設定しなければなりません。(それは、この能力パラメタの寿命が決して期限が切れないのを示します)。 0×0000の生涯値は能力エントリーを削除します。
Liebsch, et al. Experimental [Page 27] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[27ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
Data: This variable-length field has the Value of the
capability attribute encoded.
データ: この可変長の分野で、能力属性のValueをコード化します。
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.
0×0のAVP Codeが予約されているので、Capabilitiesのリストの端にいつ達するか、そして、サブオプション詰め物がどこで出発するかを決定するのにサブオプションリスト構文解析でそれを使用できます。 AVPs自身はそっと歩いています。
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.
以下に注意してください。 このドキュメントはData分野でコード化されることであるどう個々の能力属性値をコード化するかのどんな詳細な情報も提供しません。 このドキュメントの範囲の外に個々の能力パラメタの解釈に関する詳細があります。
5.2. CARD Inter-Access Router Messages
5.2. カード相互アクセスルータメッセージ
5.2.1. AR-AR Transport
5.2.1. AR-AR輸送
Because the types of access networks in which CARD might be useful are not currently deployed or, if they have been deployed, have not been extensively measured, it is difficult to know whether congestion will be a problem for inter-router CARD. Part of the research task in preparing CARD for consideration as a candidate for possible standardization is to quantify this issue. However, in order to avoid potential interference with production applications (should a prototype CARD deployment involve running over the public Internet), it seems prudent to recommend a default transport protocol that accommodates congestion.
CARDが役に立つかもしれないアクセスネットワークのタイプが現在、配布されないか、またはそれらが配布されたなら手広く測定されていないので、相互ルータCARDで混雑が問題になるかどうかを知るのは難しいです。 考慮のために可能な標準化の候補としてCARDを準備することにおける研究課題の一部はこの問題を定量化することです。 しかしながら、生産アプリケーションの潜在的干渉を避ける(プロトタイプCARD展開が、公共のインターネットを中を走らせることを伴うなら)ために、混雑を収容するデフォルトトランスポート・プロトコルを推薦するのは慎重に思えます。
This suggests that implementations of CARD MUST support and that prototype deployments of CARD SHOULD use the Stream Control Transport Protocol (SCTP) [Stew00] as the transport protocol between routers, especially if deployment over the public Internet is contemplated. SCTP supports congestion control, fragmentation, and partial retransmission based on a programmable retransmission timer. SCTP also supports many advanced and complex features, such as multiple streams and multiple IP addresses for failover, that are not necessary for experimental implementation and prototype deployment of CARD. The use of these SCTP features for CARD is not recommended at this time.
これは、CARD MUSTサポートの実装とCARD SHOULDのそのプロトタイプ展開がルータの間のトランスポート・プロトコルとしてStream Control Transportプロトコル(SCTP)[Stew00]を使用するのを示します、特に公共のインターネットの上の展開が熟考されるなら。 SCTPは、混雑がプログラマブル再送信タイマーに基づくコントロールと、断片化と、部分的な「再-トランスミッション」であるとサポートします。 また、SCTPはフェイルオーバーのための複数のストリームや複数のIPアドレスなどの多くのCARDの実験的な実装とプロトタイプ展開に必要でない高度で複雑な特徴をサポートします。 これらのSCTPの特徴のCARDの使用はこのとき、推薦されません。
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有効搭載量Data ChunkはCARDメッセージを伝えます。 相互ルータインタフェースに関するCARDメッセージはまさしくCARD RequestかCARD Replyオプションから成ります。 それぞれのSCTPメッセージのUser Data部分はメッセージタイプのためのCARDオプションを含んでいます。 例えば、CARD Replyメッセージは、SCTPメッセージのUser Data部分の中にCARD Replyオプションとすべての適切なサブオプションを含んでいることによって、構成されます。
Liebsch, et al. Experimental [Page 28] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[28ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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].
ただ一つのストリームはCARDに連続してSCTPメッセージの配送で使用されます。 断片化されない場合、各メッセージはただ一つのCARD質問か応答に対応しています。 また、ネットワーク・コンフィギュレーションか能力における変化について彼らに通知するために求められていないCARD Replyメッセージを同輩に送ることができます。 ただ一つのストリームは簡単さを提供します。 今後の研究には系列のヘッドブロッキングを防ぐ複数のストリームの使用があります。 タイムリーが相互ルータCARDの問題でなく、いかなる時もアクティブな2つのルータの間の1つ以上のCARDトランザクションであることがそこでありそうもないので、配送を命令したなら、実装は簡略化します。 SCTPヘッダーの有効搭載量プロトコルIdentifierは'CARD'です。 CARDはSeamoby SCTPポートナンバー[Ke04]を使用します。
The format of Payload Data Chunk taken from [Stew00] is shown in the following diagram.
[Stew00]から取られた有効搭載量Data Chunkの書式は以下のダイヤグラムで示されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0をタイプしてください。| 予約されます。|U|B|E| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ストリーム識別子S| ストリームSequence Number n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 有効搭載量プロトコル識別子| ユーザ
'U' bit The Unordered bit. MUST be set to 0 (zero).
'B' bit The Beginning fragment bit. See [Stew00].
'U'はUnorderedビットに噛み付きました。 0(ゼロ)に設定しなければなりません。 'B'はBeginning断片ビットに噛み付きました。 [Stew00]を見てください。
'E' bit The Ending fragment bit. See [Stew00].
'E'はEnding断片ビットに噛み付きました。 [Stew00]を見てください。
TSN Transmission Sequence Number. See [Stew00].
TSNトランスミッション一連番号。 [Stew00]を見てください。
Stream Identifier S
Identifies the CARD stream.
CARDが流すIdentifier S Identifiesを流してください。
Stream Sequence Number n
Sequence number. See [Stew00].
Sequence Number n Sequence番号を流してください。 [Stew00]を見てください。
Payload Protocol Identifier
Set to 'CARD'.
有効搭載量プロトコル識別子は'カード'にセットしました。
User Data Contains the CARD message.
ユーザData Contains CARDは通信します。
Liebsch, et al. Experimental [Page 29] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[29ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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.
始動で混雑を生成するのを避けるために、アルゴンアルゴンCARD RequestをCARsの1つに送る前に、ARsは無作為の時間をリブートの0とCARD_STARTUP_WAIT秒の間待たなければなりません。 ARが求められていないCARD Reply広告にARの情報を送るまで、CARテーブルにない別のARからCARD Requestを受けるARはARに請求してはいけませんが、むしろ待たなければなりません。 始動しているARは、彼らのCARテーブルが適切に居住されるのを確実にするために求められていないCARD RepliesをすべてのCARsに送らなければなりません。
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 Replyメッセージの頻度をCARD_MIN_UPDATE_INTERVALに制限しなければなりません、トラフィックで圧倒的なCARsを避けるために。 ARsは自由により頻繁に到着するメッセージを捨てることができます。
If a CARD deployment will never run over the public Internet, and if it is known that congestion is not a problem in the access network, alternative transport protocols MAY be appropriate vehicles for experimentation. Implementations of CARD MAY support UDP for such purposes. In that case, the researcher MUST be careful to accommodate good Internet transport protocol engineering practices, such as using retransmits with exponential backoff. In addition, whether SCTP is an appropriate transport protocol for all inter- router CARD operations is an open research question. Investigation of this issue (for example, to determine whether a lighter-weight protocol might be more appropriate than SCTP) may be of interest to some researchers.
CARD展開が公共のインターネットを決して中を走らせないで、混雑がアクセスネットワークで問題でないことが知られているなら、代替のトランスポート・プロトコルは実験のための適切な手段であるかもしれません。 CARD MAYの実装はそのような目的のためにUDPをサポートします。 その場合、研究者は使用などの良いインターネットトランスポート・プロトコルエンジニアリング方式を収容するのが指数のbackoffで再送されるのに慎重でなければなりません。 さらに、SCTPがすべての相互ルータCARD操作のための適切なトランスポート・プロトコルであるかどうかが未解決の研究問題です。 何人かの研究者にとって、この問題(例えばより軽い重さのプロトコルがSCTPより適切であるかもしれないかどうか決定する)の調査は興味深いかもしれません。
5.2.2. Protocol Payload Types
5.2.2. プロトコル有効搭載量タイプ
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インタフェースはCARD RequestオプションとCARD Replyオプションを直接SCTP User Data分野のボディーに挿入しなければなりません。 AR-ARインタフェースのCARD Requestのための一連番号をARがリブートするとき、ゼロに初期化しなければならなくて、CARD Requestメッセージを送るときはいつも、増加しなければなりません。 返答アルゴンはCARD ReplyのCARD Requestからの一連番号を含まなければなりません。 求められていないCARD Replyを送るなら、送付アルゴンは一連番号を増加しなければなりません。 一連番号を連続して増強するのに、受信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
AR-ARインタフェースでは、Capability Containerパラメタは、ARsの間に能力を伝えるのに使用されます。 任意に、能力プレフィルタリングに相互AR能力発見手順の間、Preferencesパラメタを使用できます。 有効搭載量タイプと符号化規則はものがセクション5.1のそれぞれのサブオプションタイプのためにミネソタ-ARインタフェースに説明したのと同じです。 同じTLVによってコード化された形式は、ペイロードとしてプロトコルの主なヘッダーにオプションに愛着するのに使用されます。 さらに、ARは中でCARD RequestヘッダーにT旗をはめ込むことができます。
Liebsch, et al. Experimental [Page 30] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[30ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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.
注文して、CARのための証明書を入手してください。 セクション5.1.3における、サブオプションの記述は設定がAR-ARインタフェースでどんな旗の上で禁止されているかという情報を含んでいます。
6. Security Considerations
6. セキュリティ問題
6.1. Veracity of CARD Information
6.1. カード情報の真実性
The veracity of the CARD protocol depends on the ability of an AR to obtain accurate information about geographically neighboring ARs, and to provide accurate information about its own APs and capabilities to other ARs. The CARD protocol described in the body of this document does not contain any support for determining the AR-to-AP mapping or capabilities, either for a specific AR or for a CAR. Therefore, methods for determining the accuracy of the information exchanged between ARs are out of scope for the base CARD protocol. The appendices of this document describe procedures for discovering the identities of the geographically adjacent ARs and APs (including capabilities) and discuss relevant security considerations. Alternatively, this information could be statically configured into the AR.
CARDプロトコルの真実性はARが地理的に隣接しているARsに関する的確な情報を得て、それ自身のAPsと能力に関する的確な情報を他のARsに供給する能力に依存します。 このドキュメントのボディーで説明されたCARDプロトコルはARからAPへのマッピングか能力を決定するか、特定のARまたはCARの少しのサポートも含んでいません。 したがって、ベースCARDプロトコルのための範囲の外にARsの間で交換された情報の精度を決定するためのメソッドがあります。 このドキュメントの付録は、地理的に隣接しているARsとAPs(能力を含んでいる)のアイデンティティを発見するための手順について説明して、関連セキュリティ問題について議論します。 あるいはまた、静的にこの情報をARに構成できました。
6.2. Security Association between AR and AR
6.2. ARとARとのセキュリティ協会
CARD contains support allowing ARs to exchange capability information. If this protocol is not protected from modification, a malicious attacker can modify the information. Also, if the information is delivered in plain text, a third party can read it.
CARDは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.
情報が感染されるのを防ぐために、ARsの間のCARDメッセージを認証しなければなりません。 また、必要なら、暗号化されていて、情報のプライバシーのためにSHOULDを通信させます。 オペレータのネットワークにおける2ARsの間のトラフィックが例えば公共のインターネットを横断するなら、秘密性が必要でしょうに。
Two ARs engaging in the CARD protocol MUST use IKE [HarCar98] to negotiate an IPsec ESP security association for message authentication. If confidentiality is desired, the two ARs MUST additionally negotiate an ESP security association for encryption. Replay protection SHOULD also be enabled with IKE. To protect CARD protocol messages between ARs, IPsec ESP [AtKe98] MUST be used with a non-null integrity protection and origin authentication algorithm and SHOULD be used with a non-null encryption algorithm for protecting the confidentiality of the CARD information.
CARDプロトコルに従事している2ARsが、通報認証のためにIPsec超能力セキュリティ協会を交渉するのに、IKE[HarCar98]を使用しなければなりません。 秘密性が望まれているなら、2ARsが暗号化のためにさらに、超能力セキュリティ協会を交渉しなければなりません。 保護SHOULDを再演してください、そして、また、IKEと共に可能にされてください。 ARs、IPsecの間のCARDプロトコルメッセージを保護するために、CARD情報の秘密性を保護するのに非ヌル暗号化アルゴリズムで使用される発生源認証の非ヌル保全保護、アルゴリズム、およびSHOULDと共に超能力[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はCARsのための証明書を提供できます。 ARは、CARsからCARD RequestメッセージにT旗をはめ込むことによって、証明書を要求します。 すべての証明書を送ります。
Liebsch, et al. Experimental [Page 31] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[31ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
If CARD is used to exchange information between different administrative domains, additional security policy issues may apply. Such issues are out of the scope of this document. Use of CARD between administrative domains is not recommended at this time, until the policy issues involved are more thoroughly understood.
CARDが異なった管理ドメインの間で情報交換するのに使用されるなら、追加担保政策問題は適用されるかもしれません。 このドキュメントの範囲の外にそのような問題があります。 管理ドメインの間のCARDの使用はこのとき推薦されません、問題がかかわった方針が、より徹底的に理解されるまで。
6.3. Security Association between AR and MN
6.3. ARとミネソタとのセキュリティ協会
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のふりをすることによって、にせのCARD ReplyメッセージをMNsに送ることができます。 ミネソタはARからのCARD Replyメッセージを認証しなければなりません。 ミネソタとARとのIPSecセキュリティ協会を設立するのが性能問題である傾向があるので、IKEはセキュリティ協会を設立するための適切な手段ではありません。 代わりに、SENDセキュリティ協会は使用されています[Arkko04]。 ARsはCARD ReplyメッセージのSEND Signature Optionを含まなければなりません。 IPv4とIPv6 CARDの両方に、署名オプションの形式は同じです、SEND自身がIPv6のために定義されるだけですが。 SEND署名オプション[Ke04]のためのモバイルIPv4 ICMP Foreignエージェント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].
CARD情報がリンクアクセサリーを最適化するためにARによって提供されるので、認証は全くCARD Requestsに必要ではありません。 対照的に、にせのARがミネソタをトラフィックを横取りできたにせのルータへの引き渡しに導くか、またはミネソタでサービス不能攻撃を伝播するCARD情報をミネソタに提供できたので、CARD Reply認証が必要です。 認証要件の非対称はIPv6ルータ発見[Arkko04]でその意味ありげなRouter Advertisementsと同じです。
Since CARD is a discovery protocol, confidentiality is not generally necessary on the MN-AR interface. In specific cases where different network operators share the same access network infrastructure, network operators may want to hide information about operator- specific capabilities for business reasons. The base CARD protocol contains no support for such cases. However, should such a case arise in the future, an AVP for an encrypted capability can be defined at that time.
CARDが発見プロトコルであるので、一般に、秘密性はミネソタ-ARインタフェースで必要ではありません。 異なったネットワーク・オペレータが同じアクセスネットワークインフラを共有する特定の場合では、ネットワーク・オペレータはビジネス目的のためにオペレータの特定の能力の情報を隠したがっているかもしれません。 ベースCARDプロトコルはそのような場合のサポートを全く含んでいません。 しかしながら、その時、暗号化された能力のためのAVPをそのような場合が将来起こるなら定義できます。
6.4. Router Certificate Exchange
6.4. ルータ証明書交換
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
SENDが単にIPv6で利用可能であるので、CARDがIPv4かIPv6と共に使用されるかどうかによって、証明書を入手するための手順は異なります。 IPv6では、SEND DCS/DCAを使用します。(その時、ミネソタは署名でそれが証明書を持っていないARからCARD回答を受け取って、ARの証明書チェーンを入手してください、そして、それはSHOULDです)。 共有された信じられたアンカーは、証明経路でこのためにARsを構成しなければなりません、そして、1セットの証明書でMNsを構成して、AR証明書の検証を許さなければなりません。 ミネソタは必ずそうするかもしれないというわけではありません。
Liebsch, et al. Experimental [Page 32] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[32ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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].
CGAサポートがCARDのためのOPTIONALでありCARDとCryptographically Generated Addresses(CGAs)を使用するのが必要です。 ARsのための証明書プロフィールはSEND仕様[Arkko04]で説明されます。
In IPv4, there is no DCS/DCA message for obtaining the certificate. If the MN does not have a certificate for the AR, the MN sends a CARD Request message containing the L2 ID of its current AP and one Trusted Anchor sub-option (Section 5.1.3.6) for each shared trusted anchor for which the MN has a certificate, to obtain the certification path for the current AR. The Component field of the Trusted Anchor sub-option is set to 65535 to indicate that the entire certification path is needed. No other options should be included in the request. The AR replies by sending a CARD Reply containing the L2 ID sub-option sent in the request, an Address sub-option for itself, and a Router Certificate sub-option (Section 5.1.3.7) containing one certificate in its certification path that matches one of the requested trust anchors, and no other sub-options, setting the Context-ID of all sub-options to match. The All Components field is set to the path length, and the Component field is set to the number of this component in the path. If the path is longer than one certificate, the AR sends the L2 ID sub-option and the Address sub- option in the first certificate and the other certificates in separate ICMP messages, due to the limitation on ICMP message length, with the same Context-ID set on each Route Certificate sub-option, and with the Component field properly set. The router SHOULD NOT send the trusted anchor's certificate and SHOULD send certificates in order from the certificate after the trusted anchor. If the trusted anchor option does not match any certificate, the AR returns the Trusted Anchor sub-options in the reply. The MN SHOULD immediately conduct a Certificate Revocation List (CRL) check on any certificates obtained through CARD certificate exchange, to make sure that the certificates are still valid.
IPv4には、証明書を入手することへのDCS/DCAメッセージが全くありません。 ミネソタにARのための証明書がないなら、ミネソタが現在のAPのL2 IDを含むCARD Requestメッセージと1つのTrusted Anchorサブオプションを送る、(セクション5.1 .3 .6) 証明経路を現在のARに得るためにミネソタには証明書があるそれぞれの共有された信じられたアンカーのために。 65535にTrusted AnchorサブオプションのComponent分野が、全体の証明経路が必要であることを示すように設定されます。 要求に別の選択肢を全く含むべきではありません。 L2 IDサブオプションを含むCARD Replyを送るのによるAR回答は要求を送りました、それ自体、およびRouter CertificateサブオプションのためのサブオプションのAddress、(セクション5.1 .3 .7) すべてのサブオプションのContext-IDに合うように設定して、要求された信頼のマッチ1が据えつける証明経路にもかかわらず、他のどんなサブオプションにも1通の証明書を含んでいません。 All Components分野は経路の長さに設定されます、そして、Component分野は経路のこのコンポーネントの数に設定されます。 経路が1通の証明書より長いなら、ARは別々のICMPメッセージの最初の証明書と他の証明書のサブオプションのサブオプションとAddressをL2 IDに送ります、ICMPメッセージ長における制限のため、それぞれのRoute Certificateサブオプション、および適切に設定されたComponent分野で設定された同じContext-IDと共に。 ルータSHOULD NOTは信じられたアンカーの証明書を送ります、そして、SHOULDは信じられたアンカーの後に証明書から整然としている証明書を送ります。 信じられたアンカーオプションがどんな証明書にも合っていないなら、ARは回答におけるサブオプションのTrusted Anchorを返します。 MN SHOULDはすぐに、証明書が確実にまだ有効になるようにするためにCARD証明書交換を通して入手されたどんな証明書のCertificate Revocation List(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.
CARsのための証明経路は、引き渡しの前にCARDプロトコルの一部として彼らを要求することによって、とって来られるかもしれません。 その場合、ミネソタはCAR証明書が望まれているAPのためのサブオプションのL2 IDに伴うCARD要求のサブオプションのTrusted Anchorを含めます、そして、ARは同じくらい上で返答します、L2 ID、アドレス、および証明書がAR自身の代わりにCARのためのものであるのを除いて。 新しいルータに移行するとき、これで、ミネソタはDCS/DCAかCARD証明書交換をサボることができます。
Because the amount of space in an ICMP message is limited, the router certification paths SHOULD be kept short.
ICMPメッセージのスペースの合計は限られていて、ルータ証明は経路SHOULDです。短いのが保たれてください。
Liebsch, et al. Experimental [Page 33] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[33ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
6.5. DoS Attack
6.5. DoS攻撃
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.
CARD RequestメッセージでARを圧倒できます。 AR SHOULDがレートを制限する政策を実施するので、それは、1以上のある番号の1期間あたりのメッセージを送りもしませんし、処理もしません。 ↓これは提案されたレート制限方針です。 CARDメッセージの数がCARD_REQUEST_RATEを超えているなら、レートが低下するまで、AR SHOULDは手当たりしだいにメッセージを下げ始めます。 MNs SHOULDは、CARD_REQUEST_RATEより頻繁にメッセージを送るのを避けます。 また、ARs SHOULDは、CARD_MIN_UPDATE_INTERVALより頻繁に求められていないCARD RepliesかCARD Requestsを送るのを避けますが、この場合、IPsecセキュリティ協会の存在は、未知の存在からのメッセージがすぐIPsec処理の間捨てられるのを確実にします。
MNs MUST discard CARD Replies for which there is no outstanding CARD Request, as indicated by the sequence number.
MNsはどんな傑出しているCARD Requestも一連番号によって示されるようにないCARD Repliesを捨てなければなりません。
6.6. Replay Attacks
6.6. 反射攻撃
To protect against replay attacks on the AR-AR interface, ARs SHOULD enable replay protection when negotiating the IPsec security association using IKE.
IKEを使用することでIPsecセキュリティ協会を交渉するとき、AR-ARインタフェースで反射攻撃から守るために、ARs SHOULDは反復操作による保護を可能にします。
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.
ミネソタ-ARインタフェースでは、ミネソタはどんな傑出している要求もないどんなCARD Repliesも捨てなければなりません、一連番号で決定するように。 ARsに関しては、攻撃者はミネソタから前の要求を再演できますが、ミネソタがどのような場合でも回答を無視するので、攻撃が深刻な結果なしであります。
7. Protocol Constants
7. プロトコル定数
Constant Section Default Value Meaning
--------------------------------------------------------------------
CARD_REQUEST_RETRY 5.1.1 2 seconds Wait interval before
initial retransmit
on MN-AR interface.
一定のセクションデフォルト値意味-------------------------------------------------------------------- 初期である前にCARD_REQUEST_RETRY5.1.1 2秒Wait間隔はミネソタ-ARインタフェースで再送されます。
CARD_RETRY_MAX 5.1.1 15 seconds Give up on retry
on MN-AR interface.
再試行のときにミネソタ-ARで上がっているCARD_RETRY_MAX5.1.1 15秒Giveは連結します。
CARD_STARTUP_WAIT 5.2.1 1-3 seconds Maximum startup wait
for an AR before
performing AR-AR
CARD.
Maximum始動がアルゴン-AR CARDを実行しながらARを待つCARD_STARTUP_WAIT5.2.1 1-3秒。
CARD_MIN_UPDATE_INTERVAL 5.2.1 60 seconds Minimum AR-AR update
interval.
CARD_MIN_UPDATE_INTERVAL5.2.1 60秒Minimum AR-ARは間隔をアップデートします。
Liebsch, et al. Experimental [Page 34] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[34ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
CARD_REQUEST_RATE 6.5 2 requests/ Maximum number of
sec. messages before
AR institutes rate
limiting.
AR研究所の前のメッセージが制限していると評定する秒のCARD_REQUESTの_のRATE6.5 2つの要求/最大の番号。
8. IANA Considerations
8. IANA問題
See [Ke04] for instructions on IANA allocation.
IANA配分の指示に関して[Ke04]を見てください。
9. Normative References
9. 引用規格
[Brad97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Brad97] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[Stew00] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[Stew00] スチュワート、R.、シェ、Q.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「ストリーム制御伝動プロトコル」、RFC2960(2000年10月)対パクソン
[AtKe98] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[AtKe98]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[HarCar98] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[HarCar98]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[Arkko04] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[Arkko04] ArkkoとJ.とケンフとJ.とZill、B.とP.Nikander、「安全な隣人発見(発信する)」、RFC3971、2005年3月。
[Ke04] Kempf, J., "Instructions for Seamoby and Experimental
Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[Ke04] ケンフ、J.、「Seamobyと実験的な移動性プロトコルIANA配分のための指示」、RFC4065、2005年7月。
10. Informative References
10. 有益な参照
[TKCK02] Trossen, D., Krishanmurthi, G. Chaskar, H., Kempf, J.,
"Issues in candidate access router discovery for seamless
IP-level handoffs", Work in Progress.
[TKCK02]Trossen、D.、Krishanmurthi、G.Chaskar、H.、ケンフ、J.、「候補の問題はシームレスのIP-レベルhandoffsのためにルータ発見にアクセスします」、ProgressのWork。
[MaKo03] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[MaKo03] 方法とJ.とM.Kojo、「移動性関連用語」、RFC3753、2004年6月。
[Kood03] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC
4068, July 2005.
[Kood03] Koodli、R.、エド、「速く、モバイルIPv6"、RFC4068、2005年7月に、引き渡します」。
[Funa02] Funato, D., et al., "Geographically Adjacent Access Router
Discovery Protocol", Work in Progress.
[Funa02] 船渡、D.、「地理的にアクセスルータ発見プロトコルに隣接でした」Progressの他のWork。
Liebsch, et al. Experimental [Page 35] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[35ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
[Tros03] Trossen, D., et al., "A Dynamic Protocol for Candidate
Access-Router Discovery", Work in Progress.
[Tros03] Trossen、D.、他、「候補アクセスルータ発見のためのダイナミックなプロトコル」、ProgressのWork。
[ShGi00] Shim, E. and R. Gitlin, "Fast Handoff Using Neighbor
Information", Work in Progress.
[ShGi00] 「隣人情報を使用する速い移管」という詰め物、E.、およびR.ギトリンは進行中で働いています。
[Malk03] El Malki, K., et al., "Low Latency Handoffs in Mobile
IPv4", Work in Progress.
[Malk03] 高架鉄道Malki、K.、他、「モバイルIPv4"の低遅延Handoffs、処理中の作業。」
11. Contributors
11. 貢献者
The authors would like to thank Vijay Devarapalli (Nokia) and Henrik Petander (Helsinki University of Technology) for formally reviewing the protocol specification document and providing valuable comments and input for technical discussions. The authors would also like to thank James Kempf for reviewing and for providing a lot of valuable comments and editing help.
作者は、正式にプロトコル仕様ドキュメントを再検討して、貴重なコメントと入力を提供して頂いて、技術面の協議のためにビジェイDevarapalli(ノキア)とHenrik Petander(Technologyのヘルシンキ大学)に感謝したがっています。 また、作者は、多くの貴重なコメントと編集が助けるのを論評して、提供するためのジェームス・ケンフに感謝したがっています。
12. Acknowledgements
12. 承認
The authors would like to thank (in alphabetical order) Dirk Trossen, Govind Krishnamurthi, James Kempf, Madjid Nakhjiri, Pete McCann, Rajeev Koodli, Robert C. Chalmers, and other members of the Seamoby WG for their valuable comments on the previous versions of the document, as well as for the general CARD-related discussion and feedback. In addition, the authors would like to thank Erik Nordmark for providing valuable insight about the piggybacking of CARD options upon Fast Mobile IPv6 messages.
作者は(アルファベット順に)短剣Trossenに感謝したがっています、Govind Krishnamurthi、ジェームス・ケンフ、Madjid Nakhjiri、ピートマッキャン、Rajeev Koodli、ロバートC.。チャーマーズ、およびドキュメントの旧バージョンの彼らの貴重なコメント、一般的なCARD関連の議論、およびフィードバックのためのSeamoby WGの他のメンバー。 さらに、作者は、FastのモバイルIPv6メッセージでのCARDオプションの便乗に関して貴重な見識を提供して頂いて、エリックNordmarkに感謝したがっています。
Liebsch, et al. Experimental [Page 36] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[36ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
Appendix A. Maintenance of Address Mapping Tables in Access Routers
アクセスルータにおける、アドレス変換テーブルの付録A.メインテナンス
This appendix provides information on two optional CAR table maintenance schemes for reverse address mapping in access routers. These schemes replace static configuration of the AP L2 ID-to-CAR IP address mapping in the CAR table. Details on these mechanisms are out of the scope of this document. The intention of this appendix is to provide only a basic idea on flexible extensions to the CARD protocol, as described in this document.
この付録は逆のアドレス・マッピングの2つの任意のCARテーブルメインテナンス体系の情報をアクセスルータに提供します。 これらの体系はCARテーブルでのAP L2 IDからCAR IPへのアドレス・マッピングの静的な構成を取り替えます。 このドキュメントの範囲の外にこれらのメカニズムに関する詳細があります。 この付録の意志はフレキシブルな拡大に関する基本的な考え方だけをCARDプロトコルに提供することです、本書では説明されるように。
Appendix A.1. Centralized Approach Using a Server Functional Entity
付録A.1。 サーバの機能的な実体を使用する集結されたアプローチ
The centralized approach performs CARD over the MN-AR interface as described in Section 4 of this document. Additionally, the centralized approach introduces a new entity, the CARD server, to assist the current AR in performing reverse address translation. The centralized approach requires that neighboring ARs register with the CARD server to populate the reverse address translation table. The registration of AR addresses with the CARD server is performed prior to initiation of any reverse address translation request.
集結されたアプローチはこのドキュメントのセクション4で説明されるようにミネソタ-ARインタフェースの上でCARDを実行します。 さらに、集結されたアプローチは、逆のアドレス変換を実行するのに現在のARを助けるために新しい実体、CARDサーバを紹介します。 集結されたアプローチは、隣接しているARsが逆のアドレス変換テーブルに居住するためにCARDサーバとともに記名するのを必要とします。 CARDサーバによるARアドレスの登録はどんな逆のアドレス翻訳依頼の開始の前にも実行されます。
Figure A.1 illustrates a typical scenario of the centralized CARD operation. In this example, ARs have registered their address information with a CARD server in advance. When an MN discovers the L2 ID of APs during L2 scanning, it passes one or more L2 IDs to its current AR, and the AR resolves them to the IP address of the AR. For this, the AR first checks whether the mapping information is locally available in its CAR table. If it is not, the MN's current AR queries a CARD server with the L2 ID. In response, the CARD server returns the IP address of the CAR to the current AR. Then, the current AR directly contacts the respective CAR and performs capability discovery with it. The current AR then passes the IP address of the CAR and associated capabilities to the MN. The current AR then stores the resolved IP address within its local CAR table. The centralized CARD protocol operation introduces additional signaling messages, which are exchanged between the MN's current AR and the CARD server. The signaling messages between an AR and the CARD server function are shown with the preceding identifier "AR- Server", referring to the associated interface.
図A.1は集結されたCARD操作の典型的なシナリオを例証します。 この例では、ARsはあらかじめ、CARDサーバに彼らのアドレス情報を登録しました。 ミネソタが、L2の間のAPsのL2 IDがスキャンしていると発見するとき、現在のARへのIDを1L2に通過します、そして、ARはARのIPアドレスにそれらを決議します。 これがないかどうか、ARは、最初に、CARテーブルでマッピング情報が局所的に利用可能であるかどうかチェックします。 それがそうでないなら、ミネソタの現在のARはL2 IDと共にCARDサーバについて質問します。 応答では、CARDサーバはCARのIPアドレスを現在のARに返します。 次に、現在のARは直接それぞれのCARに連絡して、それで能力発見を実行します。 そして、現在のARはCARと関連能力のIPアドレスをミネソタに向かわせます。 そして、現在のARは地方のCARテーブルの中に決心しているIPアドレスを保存します。 ARとCARDサーバ機能の間のシグナリングメッセージは「ARサーバ」という前の識別子で示されます、関連インタフェースについて言及して。集結されたCARDプロトコル操作は追加シグナリングメッセージを紹介します。(メッセージはミネソタの現在のARとCARDサーバの間で交換されます)。
An initial idea of performing reverse address translation using a centralized server is described in [Funa02].
集結されたサーバを使用することで逆のアドレス変換を実行するという初期の考えは[Funa02]で説明されます。
Liebsch, et al. Experimental [Page 37] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[37ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
+----------+
+------------>| 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
+----------+ +------------>| カード| <、-、-、-、-、-、-、-、-、-、-、-、--+ |+------------| サーバ|-------------+| || +----------+ || || || || ~~~~~~~~~~~ || (3)AR-サーバ||(4)AR-サーバ||(0) カードカード|| カード||レッジReq/Request|| 回答IP雲| 返信|| { } || || { } || |V~~~~~~~~~~~ V| +---------+ (5)アルゴンアルゴンカード要求+-----+-----+ | 電流|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 車| 車| | アルゴン| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 1 | 2 | +---------+ (6)アルゴンアルゴンカード回答+-----+-----+ ^ | | | (2)ミネソタ-アルゴン| |(7)ミネソタ-アルゴン| | カード| | カード| | 要求| V回答+---+ +---+ +--------------+ (1) AP1 L2ID+--|AP1| |AP2| | モバイル| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ +---+ +---+ | ノード|<--------------------------------+ +--------------+ (1) AP2 L2ID
Figure A.1: Centralized Approach for L2-L3 Mapping
A.1は計算します: L2-L3マッピングのための集結されたアプローチ
Appendix A.2. Decentralized Approach Using Mobile Terminals'
Handover
付録A.2。 移動体端末の引き渡しを使用する分散アプローチ
This approach performs CARD over the MN-AR interface as described in Section 4. However, it employs one additional message, called the Router Identity message, over the MN-AR interface to enable ARs to learn about the reverse address translation tables of their neighboring ARs, without being dependent on any centralized server.
このアプローチはセクション4で説明されるようにミネソタ-ARインタフェースの上でCARDを実行します。 しかしながら、ARsがそれらの隣接しているARsの逆のアドレス変換テーブルに関して学ぶのを可能にするのにミネソタ-ARインタフェースの上でRouter Identityメッセージと呼ばれる1つの追加メッセージを使います、どんな集結されたサーバにも依存していなくて。
In this approach, CAR identities in the CAR table of an AR are maintained as soft state. The entries for CARs are removed from the CAR table if they are not refreshed before the timeout period expires and are created or refreshed according to the following mechanism.
このアプローチでは、ARのCARテーブルのCARのアイデンティティは軟性国家として維持されます。 以下のメカニズムによると、CARsのためのエントリーは、彼らが壮快でないならタイムアウト時間が期限が切れる前にCARテーブルから取り除かれて、作成されるか、またはリフレッシュされます。
The key idea behind the decentralized approach is to bootstrap and maintain the association between two ARs as neighbors of each other using the actual handover of MNs occurring between them as input. The first handover between any two neighboring ARs serves as the bootstrap handover to invoke the discovery procedure, and the subsequent handover serves to refresh the association between the neighboring ARs. After the bootstrap handover, the MNs can perform
分散アプローチの後ろの主要な考えは、入力されるように彼らの間に起こりながら互いの隣人として2ARsの間でMNsの実際の引き渡しを使用することで協会を独力で進んで、維持することです。 どんな2隣接しているARsの間の最初の引き渡しが役立つ、引き渡しを独力で進んで、発見手順を呼び出してください。そうすれば、その後の引き渡しは、隣接しているARsの間の協会をリフレッシュするのに役立ちます。 引き渡しを独力で進んでください、そして、MNsは働くことができます。
Liebsch, et al. Experimental [Page 38] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[38ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
CARD and thus seamless handover using the CAR information. This idea was presented in [ShGi00] and [Tros03].
CARDとその結果、CAR情報を使用するシームレスの引き渡し。 この考えは[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.
ミネソタとその現在のARの間で実行されたCARDプロトコル操作に追加オプションを使用することによって、CARテーブルのメインテナンスをします。 このメッセージはRouter Identityメッセージとして機能します。
Upon the completion of an inter-AR handover, the MN SHOULD send a Router Identity message to its current AR. This message contains the identity (IP address) of the previous AR (pAR), and can be sent as a specific sub-option in the MN-AR CARD Request message. It SHOULD be acknowledged with the MN-AR CARD Reply. The Router Identity message enables the MN's current AR to learn that the pAR (still) has an AP whose coverage overlaps with one of the APs of the current AR, and vice versa. With this information, the MN's current AR can create or refresh an entry for the pAR as its neighbor. If handover is no longer possible between two ARs, the associated entries eventually timeout and are removed from each AR's CAR table.
相互AR引き渡しの完成のときに、MN SHOULDはRouter Identityメッセージを現在のARに送ります。 このメッセージを前のAR(pAR)のアイデンティティ(IPアドレス)を含んでいて、ミネソタ-アルゴンCARD Requestメッセージにおける特定のサブオプションとして送ることができます。 それ、SHOULD、ミネソタ-アルゴンCARD Replyと共に承認されてください。 Router Identityメッセージは、ミネソタの現在のARが、pARが(まだ、)適用範囲が現在のARのAPsの1つに重なるAPを持っていることを学ぶのを可能にします、逆もまた同様に。 この情報で、ミネソタの現在のARはpARのために隣人としてエントリーを作成するか、またはリフレッシュできます。 そして、引き渡しがもう2ARsの間で可能でなく、結局関連エントリーがタイムアウトである、各ARのCARテーブルから、取り除きます。
Prior to trusting the MN's report, however, the current AR may perform a number of checks to ensure the validity of the received information. One simple method is to verify the accuracy of the Router Identity message by sending an AR-AR CARD Request message to the pAR. The AR-AR CARD Request includes the identity of the MN. Upon receiving this message, the pAR verifies that the MN was indeed attached to it during a reasonable past interval and responds to the current AR. In this way, each handover of a MN results in a bi- directional discovery process between the two participating ARs.
しかしながら、ミネソタのレポートを信じる前に、現在のARは、受信された情報の正当性を確実にするために多くのチェックを実行するかもしれません。 1つの簡単なメソッドはアルゴンアルゴンCARD RequestメッセージをpARに送ることによってRouter Identityメッセージの精度について確かめることです。 アルゴンアルゴンCARD Requestはミネソタのアイデンティティを含んでいます。 このメッセージを受け取ると、pARはミネソタが本当に、過去の妥当な間隔の間、それに付けられて、現在のARに応じることを確かめます。 このように、ミネソタの各引き渡しは2参加ARsの間の両性愛者の方向の発見プロセスをもたらします。
Upon receiving a positive verification response, the current AR creates or refreshes, as applicable, the entry for the pAR in its local CAR table. In the former case, the current AR and the pAR exchange capabilities using the AR-AR CARD Request and AR-AR CARD Reply protocol messages. When a new entry is created, the ARs MUST exchange their reverse address translation tables. They may exchange other capabilities at this time or may defer exchange to a later time when some MN undergoing handover between them performs CARD as described in Section 4. In the latter (refresh) case, ARs may exchange capabilities or defer exchanges until a later time when another MN undergoes handover.
積極的な検証応答を受けると、現在のARは地方のCARテーブルのpARのために適切であるとしてエントリーを作成するか、またはリフレッシュします。 前の場合では、アルゴンアルゴンCARD RequestとアルゴンアルゴンCARD Replyを使用する現在のARとpAR交換能力はメッセージについて議定書の中で述べます。 新しいエントリーが作成されるとき、ARsは彼らの逆のアドレス変換テーブルを交換しなければなりません。 彼らは、このとき、他の能力を交換するか、またはそれらの間の引き渡しを受けるいくつかのミネソタがセクション4で説明されるようにCARDを実行する後の時間への交換を延期するかもしれません。 (リフレッシュします)後者の場合では、ARsは別のミネソタが引き渡しを受ける後の時間まで能力を交換するか、または交換を延期するかもしれません。
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とミネソタの現在のARの間の最初の引き渡しがCARDを使用できないことに注意してください、この引き渡しがCARテーブルを独力で進むとき。 しかしながら、長期で、引き渡しがわずかな断片に達するだけであるそのようなものは2ARsの間のうまくいっている引き渡しを合計します。 また、そのような最初の引き渡しに従事しているミネソタが引き渡し時点で非遅れの敏感なアプリケーションを実行する予定であるなら、ユーザは衝撃がわかってさえいないかもしれません。
Liebsch, et al. Experimental [Page 39] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[39ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
Appendix B. Application Scenarios
付録B.アプリケーションシナリオ
This section provides two examples of application scenarios for CARD protocol operation. One scenario describes a CARD protocol operation in a Mobile IPv6 (MIPv6) network, providing access to the infrastructure via wireless LAN Access Points and associated Access Routers. A second scenario describes CARD protocol operation in a Mobile IPv6-enabled network, which has enhanced support for fast handover integrated (Fast Mobile IPv6), also providing wireless LAN access to the infrastructure.
このセクションはアプリケーションシナリオに関する2つの例をCARDプロトコル操作に提供します。 1つのシナリオがモバイルIPv6(MIPv6)ネットワークでCARDプロトコル操作について説明します、無線LAN Access Pointsと関連Access Routersを通してインフラストラクチャへのアクセスを提供して。 2番目のシナリオはモバイルIPv6によって可能にされたネットワークでCARDプロトコル操作について説明します。(それは、また、インフラストラクチャへの無線LANアクセスを提供して、統合された(速いモバイルIPv6)速い引き渡しのサポートを機能アップしました)。
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を通してインフラストラクチャに近づく手段を持っている感動的なミネソタを仮定します。 移動性管理は、モバイル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 | - - ->>>- - - ->>>
+-----+
----------------------------- / \ +----+ | ネットワーク|---| ハ| \ / +----+ ----------------------------- | | +-----+ +-----+ | AR1|---------+ | AR2| +-----+ | +-----+ | サブネット1| |サブネット2+-----+ +-----+ +-----+ | AP1| | AP2| | AP3| +-----+ +-----+ +-----+ ^ ^ ^ \ \ \ v +-----+ | ミネソタ| - - ->>>、- - - ->>>+-----+
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
モバイルIPv6ホームのエージェント(HA)は拘束力があるキャッシュにおけるミネソタのための位置情報を維持します。 図B.1では、ミネソタが成立する、注意、-、アドレス、サブネット1AR1によって支持されて。 ミネソタが動くとき、ミネソタの現在の環境は引き渡しの候補APsとして増加するリンク品質がある一層の2無線LAN APsを提供します。
Liebsch, et al. Experimental [Page 40] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[40ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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).
意志決定を容易にしてください、そして、ARsに関連しているパラメタは決定の過程の間、考慮に入れられます。 例えば、AR関連のパラメタは、ARから支持されたアクセス技術の利用可能なQoSリソースかタイプであるかもしれません。 これらの候補ARsの能力と関連IPアドレス情報に関して学ぶために、ミネソタはCARDを実行します。 これは、候補APsのL2IDの情報を検索するのを必要とします。 その上、関連リンク品質パラメタは、迫っているAPsが引き渡しの適任の候補であるかどうかを確かめるために検索されます。AP2とAP3が適当な候補APsであるなら、ミネソタは、L2 IDサブオプションを使用して、両方のL2ID(AP2とAP3)をCARD Requestメッセージに要約して、現在の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オプションでそれぞれのCARの関連IPアドレスに記載された各L2 IDを決議します、地方のCARテーブルを利用して。 図B.1で例証された環境、ミネソタが現在付けられるのと同じであるAP2がなる候補の関連AR IPアドレスによると。(その候補は、AR1です)。 候補ARの対応するIPアドレスはAR2のアドレスです。(ARにおいて、AP3は接続されています)。 ミネソタのCARsのIPアドレスは今、AR1において知られています。(AR1はCARテーブルからCARsの能力を検索します)。 それぞれの能力パラメタがAR1のCARテーブルの関連寿命が期限が切れたダイナミックな能力をリフレッシュするようにそれには有効なエントリーがあると仮定して、AR1は能力発見のためにInter-AR CARDを実行します。 AR1のための能力情報がAR1において知られているので、それぞれのInter-アルゴンCARD RequestをAR2だけに送ります。 応答では、AR2はCARD ReplyメッセージをAR1に送り返します、Capability Containerサブオプションにおけるシグナリングメッセージで要求された能力パラメタを要約して。
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のダイナミックに発見された1つにCARD Replyメッセージでミネソタに行って戻らせます。 その上、AR1は地方のCARテーブルに関連生涯でAR2の能力パラメタを格納します。
Upon receipt of the CARD Reply message, the MN performs target AR selection, taking AR1's and AR2's capability parameters and associated APs' link-quality parameters into account. If the selected AP is AP2, no IP handover needs to be performed. If AP3 and the associated AR2 are selected, the MN needs to perform an IP handover according to the Mobile IPv6 protocol operation.
CARD Replyメッセージを受け取り次第、ミネソタは目標AR選択を実行します、AR1とAR2の能力のパラメタと関連APsのリンク品質パラメタをアカウントに取って。 選択されたAPがAP2であるなら、どんなIP引き渡しも、実行される必要がありません。 AP3と関連AR2が選択されるなら、ミネソタは、モバイルIPv6プロトコル操作に従ってIP引き渡しを実行する必要があります。
Liebsch, et al. Experimental [Page 41] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[41ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
Figure B.2 illustrates the signaling flow of the previously described application scenario of CARD within a Mobile IPv6-enabled network.
図B.2はモバイルIPv6によって可能にされたネットワークの中でCARDの以前に説明されたアプリケーションシナリオのシグナリング流動を例証します。
MN AP1 AR1 AP2 AP3 AR2
| | | | | |
| connected | | | | |
0-------------0-------0 | | |
| | | | | |
| | | | | |
| | | |
| <~~~~~~~~~L2-SCAN (AP2)~~~~~| | |
| <~~~~~~~~~L2-SCAN (AP3)~~~~~~~~~~~~~~~~~| |
| | | |
| (MN-AR) CARD Req | | | |
|-------------------->| (AR-AR) CARD Req |
| | |---------------------------------------->|
| | | (AR-AR) CARD Repl |
| (MN-AR) CARD Repl |<----------------------------------------|
|<--------------------| | | |
| | | | | |
[target AR | | | | |
selection] | | | | |
| | | | | |
// // // // // //
[either...] | | | | |
| | | | | |
|-------- L2 attach --------->| | |
| | | | | |
| connected | | | |
0---------------------0-------0 | |
| | | | | |
// // // // // //
[... or] | | | | |
| | | | | |
|--------------- L2 attach -------------->| |
| | | | | |
| connected | | | |
0-----------------------------------------0---------------------0
| | | | | |
| | |
| MIPv6 Binding Update to the HA | |
|------------------------------------------------ - - - > |
| | | | | |
ミネソタAP1 AR1 AP2 AP3 AR2| | | | | | | 接続されます。| | | | | 0-------------0-------0 | | | | | | | | | | | | | | | | | | | | <~~~~~~~~~L2-スキャン(AP2)~~~~~| | | | <~~~~~~~~~L2-スキャン(AP3)~~~~~~~~~~~~~~~~~| | | | | | | (ミネソタ-アルゴン) カードReq| | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| (アルゴンアルゴン) カードReq| | | |---------------------------------------->| | | | (アルゴンアルゴン) カードRepl| | (ミネソタ-アルゴン) カードRepl|<----------------------------------------| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、|、|、|、|、| [ARを狙ってください| | | | | 選択]| | | | | | | | | | | ////////////[どちらか] | | | | | | | | | | | |-------- L2は付きます。--------->|、|、|、|、|、|、|、|、|、| 接続されます。| | | | 0---------------------0-------0 | | | | | | | | ////////////、[…、]| | | | | | | | | | | |--------------- L2は付きます。-------------->|、|、|、|、|、|、|、|、| 接続されます。| | | | 0-----------------------------------------0---------------------0 | | | | | | | | | | MIPv6、アップデートを縛る、ハ。| | |------------------------------------------------ - - - >|| | | | | |
Figure B.2. CARD Protocol Operation within a Mobile IPv6-Enabled
Wireless LAN Network
図B.2。 モバイルIPv6によって可能にされた無線のLANネットワークの中のカードプロトコル操作
Liebsch, et al. Experimental [Page 42] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[42ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
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と同様の引き渡しのための新しいAPsのためにスキャンされます。 ARs(CARs)、ミネソタを発見するのはICMP-タイプのFastのモバイルIPv6 RtSolPrメッセージにミネソタ-アルゴンCARD Requestオプションを付けます。(それは、ミネソタの現在のAR(pAR、前の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のL2IDは、CARDプロトコルのL2 IDサブオプション(ミネソタは候補APsの複数のL2IDを現在のARに送ることができる)を使用することで要約されます。 (これは潜在的にFastのモバイル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のL2IDの受信されたリストを関連CARsのIPアドレスに決議します。 pARは、CARsの能力の情報を検索するために地方のCARテーブルをチェックします。 何かテーブル項目が期限が切れたなら、pARは、アルゴンアルゴンCARD RequestをそれぞれのCARに送ることによって、このCARの能力を取得します。 CARはアルゴンアルゴンCARD Replyメッセージで返答します、Capability Containerサブオプションですべての能力を要約して、CARD Replyオプションにそれらを付けて。 CARsの能力情報を受け取り次第、pARは、ミネソタ-アルゴンCARD ReplyオプションをFastのモバイルIPv6 PrRtAdvメッセージに付けることによって、地方のCARテーブルをアップデートして、アドレスと能力情報をミネソタに転送します。 ミネソタの引き渡しが差し迫っているとき、ミネソタはCARsの発見されたリストから新しいARと関連新しいAPを選択します。 FastのモバイルIPv6プロトコルによると、ミネソタはFast Binding Update(F-BU)メッセージで選択された新しいARについてpARに通知します、FastのモバイルIPv6プロトコルによると、pARが速い引き渡しを実行するのを許容して。
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にミネソタのCARsのアドレスと利用可能な関連することの機能があった後にpARはミネソタを代表して適切な新しいARの選択を実行できました。 ミネソタはpARがミネソタの新しいAR、アドレスを選択して、FastのモバイルIPv6 PrRtAdvメッセージにおけるCARD Replyオプションと共に選ばれた新しいARの関連能力をミネソタに送るというミネソタ-アルゴンCARD RequestメッセージAfterと共に選択の過程のための要件をpARに送らなければなりません。
Liebsch, et al. Experimental [Page 43] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[43ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
Figure B.3 illustrates how CARD protocol messages and functions work with the Fast Mobile IPv6 protocol.
図B.3はCARDプロトコルメッセージと機能がFastのモバイル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 |
| | |
ミネソタ平価NAR CAR2| | CAR1として| | | | | |-------RtSolPr------>|、|、|、| [ミネソタ-アルゴンカードReq]|-- アルゴンアルゴンカードReq*、->|、|、| |-- アルゴンアルゴンカードReq*------------>|、| | <--アルゴンアルゴンカードRepl*------------| | | <--アルゴンアルゴンカードRepl*、-| | | <、-、-、-、-、--PrRtAdv-------| | | | [ミネソタ-アルゴンカードRepl]| | | | | | | NAR選択| | | |------F-BU---------->|、-、-、-、-、-、-、--こんにちは--------->|、|、| | <、-、-、-、-、--ハッキング---------| | | <--F-後部--|--F-後部-->。| | | | | | 分離| | | | 転送| | | パケット===============>|、|、|、|、|、|、|、|、|、| 接続してください。| | | | | | | RS(FNAオプションがある)======================>|、| | <、-、-、-、-、-、-、-、-、-、--RA(NAACKオプションがある)--------| | |<================== パケットを届けてください。| | | |
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のCARテーブルのどんな能力エントリーの寿命も期限が切れた場合にだけ、pARとCARsとのCARDプロトコル相互作用が必要です。 さもなければ、CARsのアドレスと能力情報を検索する直後pARはCARテーブルから要求ミネソタに応じることができます。
Liebsch, et al. Experimental [Page 44] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[44ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
Authors' Addresses
作者のアドレス
Hemant Chaskar AirTight Networks 339 N. Bernardo Avenue Mountain View, CA 94043, USA
Hemant Chaskarの気密のネットワーク339N.ベルナルド・Avenueマウンテンビュー、カリフォルニア 94043、米国
EMail: hemant.chaskar@airtightnetworks.net
メール: hemant.chaskar@airtightnetworks.net
Daichi Funato NTT DoCoMo, Inc. Communication Systems Laboratory Wireless Laboratories 3-5, Hikarinooka, Yokosuka, Kanagawa 239-8536, Japan
大地船渡株式会社NTTドコモ通信系研究所無線電信研究所3-5、Hikarinooka、横須賀、神奈川239-8536、日本
Phone: +81-46-840-3921 EMail: funato@mlab.yrp.nttdocomo.co.jp
以下に電話をしてください。 +81-46-840-3921 メールしてください: funato@mlab.yrp.nttdocomo.co.jp
Marco Liebsch NEC Network Laboratories Kurfuersten-Anlage 36, 69115 Heidelberg, Germany
マルコLiebsch NECネットワーク研究所Kurfuersten-原基36、69115ハイデルベルグ(ドイツ)
Phone: +49 6221-90511-46 EMail: marco.liebsch@netlab.nec.de
以下に電話をしてください。 +49 6221-90511-46 メールしてください: marco.liebsch@netlab.nec.de
Eunsoo Shim Panasonic Digital Networking Laboratory Panasonic Corporation Two Research Way Princeton, NJ 08540
Eunsooのパナソニックのデジタルネットワーク研究所パナソニック詰め物の社Twoの研究道プリンストン(ニュージャージー)08540
Phone: +1-609-734-7354 EMail: eunsoo@research.panasonic.com
以下に電話をしてください。 +1-609-734-7354 メールしてください: eunsoo@research.panasonic.com
Ajoy Singh Motorola Inc 2G11, 1501 West Shure Dr. Arlington Heights, IL 60004, USA
AjoyシンモトローラInc 2G11、アーリントンハイツ、イリノイ 60004、1501の西シュアー博士米国
Phone: +1 847-632-6941 EMail: asingh1@email.mot.com
以下に電話をしてください。 +1 847-632-6941 メールしてください: asingh1@email.mot.com
Liebsch, et al. Experimental [Page 45] RFC 4066 Candidate Access Router Discovery (CARD) July 2005
Liebsch、他 実験的な[45ページ]RFC4066候補アクセスルータ発見(カード)2005年7月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Liebsch, et al. Experimental [Page 46]
Liebsch、他 実験的[46ページ]
一覧
スポンサーリンク
