Network Working Group M. Liebsch, Ed.
Request for Comments: 4066 A. Singh, Ed.
Category: Experimental H. Chaskar
D. Funato
E. Shim
July 2005
Network Working Group M. Liebsch, Ed.
Request for Comments: 4066 A. Singh, Ed.
Category: Experimental H. Chaskar
D. Funato
E. Shim
July 2005
Candidate Access Router Discovery (CARD)
候选访问路由器发现（卡）
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（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.
为了实现移动节点（MN）从一个接入路由器（AR）到另一个接入路由器（AR）的无缝IP层切换，MN需要在切换开始之前发现用于切换的候选AR（car）的身份和能力。发现汽车的行为有两个方面：识别汽车的IP地址和发现它们的能力。此过程称为“候选访问路由器发现”（CARD）。在IP层切换时，选择其性能与MN的偏好非常匹配的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. Introduction.................................................. 2
2. Terminology................................................... 3
3. CARD Protocol Functions....................................... 4
3.1. Reverse Address Translation............................. 4
3.2. Discovery of CAR Capabilities........................... 4
4. CARD Protocol Operation....................................... 4
4.1. Conceptual Data Structures.............................. 7
4.2. Mobile Node - Access Router Operation................... 8
4.3. Current Access Router - Candidate Access Router
Operation............................................... 11
4.4. CARD Protocol Message Piggybacking on the MN-AR
Interface............................................... 13
5. Protocol Messages............................................. 14
5.1. CARD Messages for the Mobile Node-Access Router
Interface............................................... 14
5.2. CARD Inter-Access Router Messages....................... 28
6. Security Considerations....................................... 31
6.1. Veracity of CARD Information............................ 31
6.2. Security Association between AR and AR.................. 31
6.3. Security Association between AR and MN.................. 32
6.4. Router Certificate Exchange............................. 32
6.5. DoS Attack.............................................. 34
6.6. Replay Attacks.......................................... 34
7. Protocol Constants............................................ 34
8. IANA Considerations........................................... 35
9. Normative References.......................................... 35
10. Informative References........................................ 35
11. Contributors.................................................. 36
12. Acknowledgements.............................................. 36
Appendix A. Maintenance of Address Mapping Tables in
Access Routers....................................... 37
Appendix A.1. Centralized Approach Using a Server Functional
Entity.......................................... 37
Appendix A.2. Decentralized Approach Using Mobile Terminals'
Handover........................................ 38
Appendix B. Application Scenarios................................ 40
Appendix B.1. CARD Operation in a Mobile IPv6-Enabled Wireless
LAN Network..................................... 40
Appendix B.2. CARD Operation in a Fast Mobile IPv6-Enabled
Network......................................... 43
5. Protocol Messages............................................. 14
5.1. CARD Messages for the Mobile Node-Access Router
Interface............................................... 14
5.2. CARD Inter-Access Router Messages....................... 28
6. Security Considerations....................................... 31
6.1. Veracity of CARD Information............................ 31
6.2. Security Association between AR and AR.................. 31
6.3. Security Association between AR and MN.................. 32
6.4. Router Certificate Exchange............................. 32
6.5. DoS Attack.............................................. 34
6.6. Replay Attacks.......................................... 34
7. Protocol Constants............................................ 34
8. IANA Considerations........................................... 35
9. Normative References.......................................... 35
10. Informative References........................................ 35
11. Contributors.................................................. 36
12. Acknowledgements.............................................. 36
Appendix A. Maintenance of Address Mapping Tables in
Access Routers....................................... 37
Appendix A.1. Centralized Approach Using a Server Functional
Entity.......................................... 37
Appendix A.2. Decentralized Approach Using Mobile Terminals'
Handover........................................ 38
Appendix B. Application Scenarios................................ 40
Appendix B.1. CARD Operation in a Mobile IPv6-Enabled Wireless
LAN Network..................................... 40
Appendix B.2. CARD Operation in a Fast Mobile IPv6-Enabled
Network......................................... 43
IP mobility protocols, such as Mobile IP, enable mobile nodes to execute IP-level handover among access routers. Work is underway [Kood03][Malk03] to extend the mobility protocols to allow seamless IP handover. Seamless IP mobility protocols will require knowledge of candidate access routers (CARs) to which a mobile node can be transferred. The CAR discovery protocol enables the acquisition of information about the access routers that are candidates for the mobile node's next handover.
IP移动协议，例如移动IP，使移动节点能够在接入路由器之间执行IP级切换。[Kood03][Malk03]正在扩展移动协议，以实现无缝IP切换。无缝IP移动协议需要了解移动节点可以传输到的候选接入路由器（CAR）。汽车发现协议允许获取关于接入路由器的信息，这些路由器是移动节点下一次切换的候选路由器。
CAR discovery involves identifying a CAR's IP address and the capabilities that the mobile node might use for a handover decision. There are cases in which a mobile node has a choice of CARs. The mobile node chooses one according to a match between the mobile node's requirements for a handover candidate and the CAR's capabilities. However, the decision algorithm itself is out of the scope of this document.
车辆发现涉及识别车辆的IP地址和移动节点可能用于切换决策的功能。在某些情况下，移动节点可以选择汽车。移动节点根据移动节点对切换候选者的要求与车辆的能力之间的匹配来选择一个。但是，决策算法本身不在本文档的范围内。
The problem statement for CAR discovery is documented in [TKCK02]. In this document, a protocol is described to perform CAR discovery. Section 3 describes two main functions of the CAR discovery protocol. Section 4 describes the core part of the CARD protocol operation. The protocol message format is described in Section 5. Section 6 discusses security considerations, and Section 7 contains a table of protocol parameters. Appendix A contains two alternative techniques for dynamically constructing the CAR table mapping between the access point L2 ID and Access Router IP address, which is necessary for reverse address translation. The default method is static configuration. Appendix B contains two sample scenarios for using CARD.
[TKCK02]中记录了车辆发现的问题说明。在本文档中，描述了执行车辆发现的协议。第3节描述了汽车发现协议的两个主要功能。第4节描述了卡协议操作的核心部分。协议消息格式见第5节。第6节讨论安全注意事项，第7节包含协议参数表。附录A包含两种备选技术，用于动态构建接入点L2 ID和接入路由器IP地址之间的CAR表映射，这是反向地址转换所必需的。默认方法是静态配置。附录B包含两个使用信用卡的示例场景。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[Brad97]中所述进行解释。
This document uses terminology defined in [MaKo03].
本文件使用[MaKo03]中定义的术语。
In addition, the following terms are used:
此外，还使用了以下术语：
Access Router (AR)
接入路由器（AR）
An IP router residing in an access network and connected to one or more APs. An AR offers IP connectivity to MNs.
驻留在接入网中并连接到一个或多个接入点的IP路由器。AR提供到MNs的IP连接。
Candidate AR (CAR)
候选人AR（汽车）
An AR to which an MN has a choice when performing IP-level handover.
MN在执行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被视为切换候选者时，MN可能感兴趣的AR提供的服务的特征。
L2 ID
二级ID
An identifier of an AP that uniquely identifies that AP. For example, in 802.11, this could be a MAC address of an AP.
唯一标识该AP的AP标识符。例如，在802.11中，这可能是AP的MAC地址。
CARD Initiating Trigger
卡启动触发器
An L2 trigger used to initiate the CARD process. For example, a MN can initiate CARD as soon as it detects the L2 ID of a new AP during link layer scan.
用于启动卡处理的L2触发器。例如，MN可以在链路层扫描期间检测到新AP的L2 ID后立即启动卡。
Access Point (AP)
接入点（AP）
A wireless access point, identified by a MAC address, providing service to the wired network for wireless nodes.
由MAC地址标识的无线接入点，为无线节点的有线网络提供服务。
The CARD protocol accomplishes the following functions.
卡协议完成以下功能。
If an MN can listen to the L2 IDs of new APs prior to making a decision about IP-level handover to CARs, a mechanism is needed for reverse address translation. This function of the CARD protocol enables the MN to map the received L2 ID of an AP to the IP address of the associated CAR that connects to the AP. To get the CAR's IP address, the MN sends the L2 ID of the AP to the current AR, and the current AR provides the associated CAR's IP address to the MN.
如果MN可以在决定将IP级别切换到CARs之前侦听新AP的L2 ID，则需要一种反向地址转换机制。卡协议的此功能使MN能够将接收到的AP的L2 ID映射到连接到AP的相关车辆的IP地址。为了获得汽车的IP地址，MN向当前AR发送AP的L2 ID，并且当前AR向MN提供相关汽车的IP地址。
Information about the capabilities of CARs can assist the MN in making optimal handover decisions. This capability information serves as input to the target AR selection algorithm. Some of the capability parameters of CARs can be static, whereas others can change with time.
关于车辆性能的信息可以帮助MN做出最佳的切换决策。该能力信息用作目标AR选择算法的输入。汽车的一些性能参数可能是静态的，而另一些则可能随时间而变化。
A definition of capabilities is out of the scope of this document. Encoding rules for capabilities and the format of a capability container for capability transport are specified in Section 5.
能力的定义不在本文档的范围内。第5节规定了能力编码规则和能力传输能力容器的格式。
The CARD protocol allows MNs to resolve the L2 ID of one or more APs to the IP addresses of the associated CARs. The L2 IDs are typically discovered during an operation by the MN and are potential handover candidates. Additionally, CARD allows MNs to discover particular capabilities associated with the CARs, such as available bandwidth, that might influence the handover decision of the MN. Furthermore, the protocol allows ARs to populate and maintain their local CAR table (Section 4.1) with the capabilities of CARs. For this, the CARD protocol makes use of CARD Request and CARD Reply messages
卡协议允许MNs将一个或多个AP的L2 ID解析为相关车辆的IP地址。L2 ID通常在MN的操作期间被发现，并且是潜在的切换候选。此外，该卡允许MNs发现与车辆相关联的特定能力，例如可能影响MN切换决策的可用带宽。此外，该协议允许ARs使用CARs的功能填充和维护其本地CAR表（第4.1节）。为此，卡协议使用卡请求和卡回复消息
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).
MN与其当前AR之间（第5.1.2节），以及MN当前AR与单个车辆之间（第5.2.2节）。
To allow an MN to retrieve a CAR's address and capability information, the CARD Request and CARD Reply messages used between an MN and its current AR may contain one or more access points' L2 IDs and the IP addresses of associated CARs, respectively. Optionally, the CARD Reply messages can also contain a CAR's capability information. A CAR's capabilities are specified as a list of attribute-value pairs, which are conveyed in a Capability Container message parameter.
为了允许MN检索汽车的地址和能力信息，MN与其当前AR之间使用的卡请求和卡回复消息可分别包含一个或多个接入点的L2 ID和相关汽车的IP地址。或者，卡回复消息还可以包含汽车的性能信息。汽车的能力被指定为属性值对列表，这些属性值对在能力容器消息参数中传递。
Information about CARs and associated capabilities MAY be used by the MN to perform target access router selection during its IP handover. The current AR returns replies according to its CAR table (see Section 4.1) and returns a RESOLVER ERROR (see Section 5.1.3.1) if the request cannot be resolved.
在其IP切换期间，MN可以使用关于CARs和相关能力的信息来执行目标接入路由器选择。当前AR根据其CAR表（见第4.1节）返回回复，如果请求无法解决，则返回解析程序错误（见第5.1.3.1节）。
The CARD protocol also enables an MN to optionally indicate its preferences on capabilities of interest to its current AR by including the Preferences message parameter in the CARD Request message. The MN's current AR MAY use this information to perform optional capability pre-filtering for optimization purposes, and it returns only these capabilities of interest to the requesting MN. The format of this optional Preferences message parameter is described in Section 5.1.3.2.
卡协议还允许MN通过在卡请求消息中包含preferences消息参数，选择性地指示其对其当前AR感兴趣的能力的偏好。MN的当前AR可以使用该信息来执行可选的能力预过滤以达到优化目的，并且它仅将这些感兴趣的能力返回给请求MN。第5.1.3.2节描述了此可选首选项消息参数的格式。
Optionally, the MN can provide its current AR with a list of capability attribute-value pairs, indicating not only the capability parameters (attributes) required for capability pre-filtering, but also a specific value for a particular capability. This allows the MN's current AR to perform CAR pre-filtering and to send only address and capability information of CARs whose capability values meet the requirements of the MN back to the requesting MN. The format of this optional Requirements message parameter is described in Section 5.1.3.3.
可选地，MN可以向其当前AR提供能力属性值对的列表，该列表不仅指示能力预过滤所需的能力参数（属性），而且还指示特定能力的特定值。这允许MN的当前AR执行CAR预过滤，并仅将其能力值满足MN要求的CAR的地址和能力信息发送回请求MN。第5.1.3.3节描述了该可选需求消息参数的格式。
For example, using the optional Preferences message parameter, an MN may indicate to its current AR that it is interested only in IEEE802.11a interface-specific capability parameters, as this is the only interface the MN has implemented. The MN's current AR sends back only CARs with IEEE802.11a-specific capabilities. Similarly, using the optional Requirements message parameter, an MN may indicate to its current AR that it is only interested in CARs that can satisfy a given QoS constraint. Here, an MN sends the respective QoS attribute with the QoS constraint value to its current AR using the optional Requirements message parameter. The QoS constraint is denoted as an attribute-value pair and encapsulated with the
例如，使用可选的首选项消息参数，MN可以向其当前AR指示它只对IEEE802.11a接口特定的能力参数感兴趣，因为这是MN实现的唯一接口。MN当前的AR仅发回具有IEEE802.11a特定功能的汽车。类似地，使用可选的Requirements消息参数，MN可以向其当前AR指示它只对能够满足给定QoS约束的汽车感兴趣。这里，MN使用可选需求消息参数将具有QoS约束值的各个QoS属性发送到其当前AR。QoS约束表示为属性值对，并用
Requirements message parameter, which is appended to the MN-originated CARD Request message. The Requirements message parameter may be used to indicate the cutoff values of the capabilities for any desired CARs. According to the received optional list of attributes in the Preferences parameter or a list of attribute-value pairs in the Requirements message parameter, the MN's current AR MAY use these parameters for deciding the content of the solicited CARD Reply message, which is to be sent back to the MN. Alternatively, if the MN's current AR does not perform optimization with regard to capability or CAR pre-filtering, the current AR MAY choose to silently ignore the optional Requirements and Preferences message parameter as received in the CARD Request message.
Requirements message参数，附加到MN原始卡请求消息。Requirements message（要求信息）参数可用于指示任何所需车辆的能力截止值。根据首选项参数中接收到的可选属性列表或需求消息参数中的属性值对列表，MN的当前AR可以使用这些参数来决定请求的卡回复消息的内容，该消息将被发送回MN。或者，如果MN的当前AR没有执行关于能力或车辆预过滤的优化，则当前AR可以选择静默地忽略在卡请求消息中接收的可选要求和首选项消息参数。
The MN can additionally request from the AR a certification path that is anchored at a certificate from a shared, trusted anchor. The MN includes in the CARD Request message a list of trusted anchors for which the MN has a certificate, and the AR replies with the certification path. If no match is found, the AR returns the trusted anchor names from the CARD Request. The MN can ask for a chain for either the current AR or a CAR. If the trusted anchor list is accompanied by an AP L2 ID for the MN's current AP, the returned chain is for the current AR. If the L2 ID is for an AP that the MN has heard during scanning and is not connected to the current AR, the returned chain is for a CAR. The chain is returned as a sequence of CARD Reply messages, each message containing a single certificate, the L2 identifier for the AP sent in the CARD Request, and a router address for the CAR (or for the AR itself if a request was made for the AR). When the chain is complete, the MN can use it to obtain the AR's certified key and thereby validate signatures on CARD messages and other messages between the MN and the current AR. The MN only has to send the trusted anchor option if it does not have the certification path for the AR already cached. If the MN has the certification path cached, through preconfiguration, through previous receipt of the chain from this router, or by having received the chain through a previous router, then the trusted anchor does not have to be sent. More information about certificate exchange and its use in CARD security can be found in Section 6.
MN还可以从AR请求一个证书路径，该路径锚定在来自共享的可信锚定的证书上。MN在卡请求消息中包括MN具有证书的受信任锚的列表，AR使用证书路径进行回复。如果未找到匹配项，AR将从卡请求返回受信任的锚名称。MN可以为当前AR或汽车请求链条。如果受信任锚列表附带MN当前AP的AP L2 ID，则返回的链用于当前AR。如果L2 ID用于MN在扫描过程中听到的AP，且未连接到当前AR，则返回的链用于汽车。链以卡回复消息序列的形式返回，每条消息包含一个证书、卡请求中发送的AP的L2标识符以及CAR的路由器地址（或AR本身的路由器地址，如果AR被请求）。当链完成时，MN可以使用它来获取AR的认证密钥，从而验证MN和当前AR之间的卡消息和其他消息上的签名。MN只有在没有已缓存AR的认证路径时才需要发送可信锚选项。如果MN通过预配置、通过先前从该路由器接收链或通过先前路由器接收链而缓存了认证路径，则不必发送可信锚。有关证书交换及其在卡安全中的使用的更多信息，请参见第6节。
The CARD protocol operation, as described in this section, distinguishes signaling messages exchanged between an MN and its current AR from those exchanged between ARs. Hence, descriptions of signaling messages in the following sections have preceding identifiers referring to the associated interface. Messages that are exchanged between an MN and AR are designated as "MN-AR", and messages between ARs are designated as "AR-AR".
如本节所述，卡协议操作将MN与其当前AR之间交换的信令消息与AR之间交换的信令消息区分开来。因此，以下部分中的信令消息的描述具有参考相关接口的先前标识符。MN和AR之间交换的消息被指定为“MN-AR”，AR之间的消息被指定为“AR-AR”。
+--------------+ (1a)AR-AR CARD Request +----------+
| Current |------------------------->| CAR |
| AR |<-------------------------| |
+--------------+ (2a)AR-AR CARD Reply +----------+
^ |
| | MN-AR
MN-AR | | CARD Reply(3m)
CARD Request(2m) V
+--------------+
| Mobile |
| Node |<-- CARD Init Trigger
+--------------+ (1m)
+--------------+ (1a)AR-AR CARD Request +----------+
| Current |------------------------->| CAR |
| AR |<-------------------------| |
+--------------+ (2a)AR-AR CARD Reply +----------+
^ |
| | MN-AR
MN-AR | | CARD Reply(3m)
CARD Request(2m) V
+--------------+
| Mobile |
| Node |<-- CARD Init Trigger
+--------------+ (1m)
Figure 1: MN-initiated CARD Protocol Overview
图1:MN启动的卡协议概述
Figure 1 describes the operation of the MN-AR CARD Request/Reply protocol and AR-AR CARD Request/Reply protocol. On receipt of the access points' L2 IDs or the appearance of a CARD initiation trigger (1m), the MN may pass on one or more AP L2 IDs to its current AR using the MN-AR CARD Request message (2m). If the MN wants its AR to perform capability discovery in addition to reverse address translation, this must be indicated in the MN-AR CARD Request message by setting the C-flag. If the C-flag is not set, the AR receiving the CARD Request message will perform only reverse address translation. The MN's current AR resolves the L2 ID to the IP address of the associated CAR or, if the MN has not attached any L2 ID message parameters, just reads out all CARs' IP address information using the reverse address translation information (L2 ID to IP address mapping) from its local CAR table. The current AR then returns to the MN using the MN-AR CARD Reply message (3m), the IP addresses of any CARs, each CAR's set of L2 IDs with CANDIDATE indicated in the L2 ID sub-option status field, and, if capability information has been requested, associated capabilities.
图1描述了MN-AR卡请求/应答协议和AR-AR卡请求/应答协议的操作。在接收到接入点的L2 id或出现卡启动触发器（1m）时，MN可以使用MN-AR卡请求消息（2m）将一个或多个AP L2 id传递给其当前AR。如果MN希望其AR除了执行反向地址转换外还执行能力发现，则必须通过设置C标志在MN-AR卡请求消息中指出这一点。如果未设置C标志，则接收卡请求消息的AR将仅执行反向地址转换。MN的当前AR将L2 ID解析为关联CAR的IP地址，或者，如果MN没有附加任何L2 ID消息参数，则仅使用其本地CAR表中的反向地址转换信息（L2 ID到IP地址映射）读取所有CAR的IP地址信息。然后，当前AR使用MN-AR卡回复消息（3m）、任何车辆的IP地址、每个车辆的L2 ID集合以及L2 ID子选项状态字段中指示的候选，以及（如果已请求能力信息）相关能力返回MN。
For the AR-AR CARD Request/Reply protocol, the requesting AR sends a CARD Request message to its peer when the CAR table entries time out (1a). The peer returns a CARD Reply message with the requested information (2a).
对于AR-AR卡请求/应答协议，当CAR表条目超时时，请求AR向其对等方发送卡请求消息（1a）。对等方返回带有请求信息的卡回复消息（2a）。
ARs SHALL maintain an L2-L3 address mapping table (CAR table) that is used to resolve L2 IDs of candidate APs to the IP address of the associated CAR. By default, this address-mapping table is configured statically for the CARD protocol operation. Optionally, the CAR table MAY be populated dynamically. Two possible approaches are described in Appendices A.1 and A.2.
ARs应维护一个L2-L3地址映射表（CAR表），用于将候选AP的L2 ID解析为相关CAR的IP地址。默认情况下，此地址映射表是为卡协议操作静态配置的。或者，可以动态填充CAR表。附录A.1和A.2中描述了两种可能的方法。
ARs SHOULD also keep and maintain individual CARs' capabilities in the local CAR table, with the associated capability lifetime taken into account. If the lifetime of an individual capability entry has expired, the respective capability information is updated. An AR may also initiate capability exchange prior to expiration of the capabilities associated with a CAR in the CAR table, thereby populating its CAR table. The AR's CAR table may be implemented differently; therefore additional details are not provided here. ARs MUST maintain their own AP-to-AR mappings and capability information in their CAR tables, in order to provide newly booted MNs with this information so that an MN can obtain the AR's certification path.
AR还应在本地CAR表中保留和维护单个CAR的能力，并考虑相关的能力寿命。如果单个能力条目的生存期已过期，则会更新相应的能力信息。AR还可以在与CAR表中的CAR相关联的能力到期之前启动能力交换，从而填充其CAR表。AR的CAR表可以以不同的方式实现；因此，此处不提供其他详细信息。AR必须在其CAR表中维护自己的AP到AR映射和能力信息，以便为新启动的MN提供此信息，以便MN可以获得AR的认证路径。
MNs SHOULD maintain discovered address and capability information of CARs in a local cache to avoid requesting the same information repeatedly and to select an appropriate target AR from the list of CARs as quickly as possible when a handover is imminent.
MNs应将发现的车辆地址和能力信息保存在本地缓存中，以避免重复请求相同的信息，并在即将移交时尽快从车辆列表中选择适当的目标AR。
To initiate CARD, an MN sends a CARD Request to its current AR, requesting it to resolve the L2 ID of nearby access points to the IP address of associated CARs and also obtain capability parameters associated with these CARs. If the requesting MN wants its current AR to resolve specific L2 IDs, the MN-AR CARD Request MUST contain the CARD protocol-specific L2 ID message parameters. If the MN wants its AR to perform only reverse address translation without appending the CARs' capabilities, the MN refrains from setting the C-flag in the CARD Request message. If the MN wants to perform capability discovery, the MN MUST set the C-flag in the CARD Request message. The CARD Request MAY also contain the Preferences or Requirements message parameter, indicating the MN's preferences on capability attributes of interest or its requirements on CARs' capability attribute-value pairs.
为了启动卡，MN向其当前AR发送卡请求，请求其将附近接入点的L2 ID解析为相关车辆的IP地址，并获取与这些车辆相关的能力参数。如果请求MN希望其当前AR解析特定的L2 ID，则MN-AR卡请求必须包含卡协议特定的L2 ID消息参数。如果MN希望其AR只执行反向地址转换而不附加CARs的功能，MN将避免在卡请求消息中设置C标志。如果MN想要执行能力发现，MN必须在卡请求消息中设置C标志。卡请求还可能包含首选项或要求消息参数，指示MN对感兴趣的能力属性的首选项或其对CARs能力属性值对的要求。
If the MN appends multiple L2 ID sub-options to a CARD Request, the AR MUST assume that each L2 ID is associated with an AP that connects to a different CAR. Since L2 IDs, address information, and capability information are transmitted with separate sub-options, each sub-option carries a Context-ID, to allow parameters that belong together to be matched. Therefore, the MN MUST assign different Context-ID values to the L2 ID sub-options it appends to the CARD Request message. The Status-Code field of the L2 ID sub-option MUST always be set to NONE (0x00) by the MN. The MN MUST set the sequence number to a randomly generated value, and the AR MUST include the sequence number in all messages of the reply. If the reply spans multiple messages, each message contains the same sequence number.
如果MN向卡请求附加多个L2 ID子选项，AR必须假设每个L2 ID与连接到不同汽车的AP相关联。由于L2 ID、地址信息和能力信息通过单独的子选项传输，因此每个子选项都携带一个上下文ID，以允许匹配属于一起的参数。因此，MN必须为附加到卡请求消息的L2 ID子选项分配不同的上下文ID值。MN必须始终将L2 ID子选项的状态代码字段设置为NONE（0x00）。MN必须将序列号设置为随机生成的值，AR必须在回复的所有消息中包含序列号。如果回复跨越多条消息，则每条消息包含相同的序列号。
Upon receipt of the corresponding MN-AR CARD Reply message, the MN correlates the CARD Reply with the appropriate CARD Request message and then processes all MN-AR CARD Reply message parameters to retrieve its CAR's address and capability information. If the MN is unable to correlate the CARD Reply with any previously sent CARD Request messages, the MN SHOULD silently discard the reply. This may happen when the MN reboots after sending a CARD Request message to the connected AR.
在收到相应的MN-AR卡回复消息后，MN将卡回复与相应的卡请求消息相关联，然后处理所有MN-AR卡回复消息参数，以检索其CAR的地址和能力信息。如果MN无法将卡回复与之前发送的任何卡请求消息相关联，MN应自动放弃回复。当MN向连接的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_Request_RETRY秒内未收到卡回复，MN使用指数退避来重新传输卡请求。重新传输的卡请求必须具有与原始卡相同的序列号。除了本质上较大的认证路径外，AR应尝试将卡回复中的信息限制为单个消息。如果这是不可能的，AR可以在多个消息中发送回复。回复的最后一条消息必须始终在卡回复选项中设置L标志，以指示该消息是相关序列号的最后一条消息。AR重新传输对卡请求的回复必须始终发送完整的卡回复序列。Trusted Anchor子选项和Router Certificate子选项提供了一种方式，在承载认证路径的卡应答跨越多条消息并且其中一条消息丢失的情况下，MN可以通过该方式请求认证路径中的特定证书。但是，MN必须将初始卡回复中未收到的特定证书请求视为新请求，并且必须使用不同的序列号。
Processing the Context-ID of Address sub-options allows the MN to assign the resolved IP address of a specific CAR to an L2 ID.
处理地址子选项的上下文ID允许MN将特定汽车的解析IP地址分配给L2 ID。
In some cases, an L2 ID parameter is present in a CARD Reply message. The Status-Code field in the L2 ID parameter indicates one of the following reasons for its being sent toward the MN.
在某些情况下，卡回复消息中存在L2 ID参数。L2 ID参数中的Status Code字段表示将其发送到MN的以下原因之一。
RESOLVER ERROR Status-Code indication: If the MN's current AR could not resolve a particular L2 ID, this status code is returned to the MN.
解析程序错误状态代码指示：如果MN的当前AR无法解析特定的L2 ID，则此状态代码将返回给MN。
MATCH Status-Code indication: If an L2 ID is encountered that shares a CAR with a previously resolved L2 ID, the AR returns MATCH to the MN. This status code indicates that the Context-ID of this particular L2 ID sub-option has been set to the Context-ID of the associated CAR's Address and Capability Container sub-option, which is sent with this CARD Reply message. This approach avoids sending the same CAR's address and capability information multiple times with the same CARD Reply message in case two or more L2 IDs resolve to the same
匹配状态代码指示：如果遇到一个L2 ID与以前解析的L2 ID共享一辆汽车，AR会将匹配返回给MN。此状态代码表示此特定L2 ID子选项的上下文ID已设置为关联汽车地址和能力容器子选项的上下文ID，该ID随此卡回复消息一起发送。这种方法避免了在两个或多个L2 ID解析为相同的情况下，使用相同的卡回复消息多次发送同一辆车的地址和能力信息
CAR. An MN uses the Context-ID received in the L2 ID sub-option as the key to find the serving CAR of the given AP from the content of the received CARD Reply message.
汽车MN使用在L2 ID子选项中接收的上下文ID作为密钥，从接收到的卡回复消息的内容中查找给定AP的服务车。
CANDIDATE Status-Code indication: If the MN does not append any L2 ID to the CARD Request, the AR sends back the L2 ID and address information of all CARs. Because the received parameters' Context-IDs cannot be correlated with an L2 ID's Context-ID of a previously sent request, the AR chooses values for the Context-ID and marks these candidate L2 IDs with CANDIDATE in the status code of the distributed L2 IDs. However, individual values of L2 IDs' Context-ID allow the MN to assign a particular L2 ID to the associated Address and the possibly received Capability Container sub-option.
候选状态代码指示：如果MN没有向卡请求附加任何L2 ID，AR会发回所有车辆的L2 ID和地址信息。因为接收到的参数的上下文ID不能与先前发送的请求的L2 ID的上下文ID相关联，所以AR选择上下文ID的值，并在分布式L2 ID的状态代码中将这些候选L2 ID标记为候选。然而，L2 ID的上下文ID的单个值允许MN将特定的L2 ID分配给关联的地址和可能接收到的能力容器子选项。
As described in Section 4.5, an MN can use CARD when it initially boots up to determine whether piggyback operation is possible. An MN can also use CARD initially to determine the capabilities and certificates for an AR on which it boots up or if it cannot obtain the certificates beforehand. To do this, the MN includes an L2 Identifier option with its current AP L2 ID and the requested information. The AR replies with its own information.
如第4.5节所述，MN可以在初始启动时使用卡来确定是否可以进行搭载操作。MN还可以最初使用卡来确定其启动的AR的能力和证书，或者如果不能事先获得证书。为此，MN包括一个L2标识符选项及其当前AP L2 ID和请求的信息。AR用自己的信息进行回复。
Upon receipt of an MN's MN-AR CARD Request, the connected AR SHALL resolve the requested APs' L2 ID to the IP address of any associated CARs. If no L2 ID parameter has been sent with the MN-AR CARD Request message, the receiving AR retrieves all CARs' IP addresses and, if the C-flag was set in the request, the capability information.
收到MN的MN-AR卡请求后，连接的AR应将请求的AP的L2 ID解析为任何相关车辆的IP地址。如果MN-AR卡请求消息未发送L2 ID参数，则接收AR检索所有车辆的IP地址，如果请求中设置了C标志，则检索能力信息。
In the first case, where the AR resolves only requested L2 IDs, the AR does not send back the L2 ID to the requesting MN. If, however, two or more L2 IDs match the same CAR information, the L2 ID sub-option is sent back to the MN, indicating a MATCH in the Status-Code field of the L2 ID. Furthermore, the AR sets the Context-ID of the returned L2 ID to the value of the resolved CAR's L2 ID, Address, and Capability Container sub-option. If an AR cannot resolve a particular L2 ID, an L2 ID sub-option is sent back to the MN, indicating a RESOLVER ERROR in the L2 ID sub-option's Status-Code field.
在第一种情况下，AR仅解析请求的L2 ID，AR不会将L2 ID发送回请求MN。但是，如果两个或多个L2 ID匹配相同的车辆信息，则L2 ID子选项将发送回MN，指示L2 ID的状态代码字段中存在匹配项。此外，AR将返回的L2 ID的上下文ID设置为解析的车辆L2 ID、地址和能力容器子选项的值。如果AR无法解析特定的L2 ID，则会将L2 ID子选项发送回MN，指示L2 ID子选项的状态代码字段中存在解析程序错误。
In the second case, where the AR did not receive any L2 ID with a CARD Request, all candidate APs' L2 IDs are sent to a requesting MN with the CARD Reply message. The AR marks the Status-Code of individual L2 IDs as CANDIDATE, indicating to the MN that the
在第二种情况下，在AR没有接收到任何具有卡请求的L2 ID的情况下，所有候选ap的L2 ID被发送到具有卡回复消息的请求MN。AR将各个L2 ID的状态代码标记为候选，向MN指示
associated Context-ID cannot be matched with the ID of a previously sent request.
关联的上下文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.
在任何情况下，AR必须将地址和能力容器子选项的上下文ID设置为与相关L2 ID子选项相同的值。
Optionally, when allowed by local policies and supported by respective ARs for capability discovery, the AR MAY retrieve a subset of capabilities or CARs, satisfying the optionally appended Preferences and Requirement message parameter, from its local CAR table. CARs' address information and associated capabilities are then delivered to the MN using the MN-AR CARD Reply message. The CARs' IP address and the capabilities SHALL be encoded according to the format for CARD protocol message parameters as defined in Section 5.1.3 of this document. The capabilities are encoded as attribute-value pairs, which are encapsulated in a Capability Container message parameter according to the format defined in Section 5.1.3.4. The responding current AR SHALL copy the sequence number received in the MN-AR CARD Request to the MN-AR CARD Reply.
可选地，当本地策略允许且各AR支持能力发现时，AR可从其本地CAR表检索满足可选附加的首选项和需求消息参数的能力或CAR子集。然后，使用MN-AR卡回复消息将CARs的地址信息和相关功能传递给MN。CARs的IP地址和能力应根据本文件第5.1.3节中定义的卡协议消息参数格式进行编码。能力编码为属性值对，根据第5.1.3.4节中定义的格式封装在能力容器消息参数中。响应的当前AR应将MN-AR卡请求中收到的序列号复制到MN-AR卡回复中。
The MN's current AR MAY initiate capability exchange with CARs either when it receives an MN-AR CARD Request or when it detects that one or more of its local CAR table's capability entries' lifetimes are about to expire. An AR SHOULD preferentially utilize its CAR table to fulfill requests rather than signal the CAR directly, and it SHOULD keep the CAR table up to date for this purpose, in order to avoid injecting unnecessary delays into the MN response.
MN的当前AR可在接收到MN-AR卡请求或检测到其本地CAR表的一个或多个能力条目的生存期即将到期时，启动与CARs的能力交换。AR应优先利用其CAR表来满足请求，而不是直接向CAR发送信号，并且应为此目的使CAR表保持最新，以避免在MN响应中注入不必要的延迟。
The AR SHOULD issue an AR-AR CARD Request to the respective CARs if complete capability information of a CAR is not available in the current AR's CAR table, or if such information is expired or about to expire. The AR-AR CARD Request message format is defined in Section 5.2.2. The sequence number on the AR-AR interface starts with zero when the AR reboots. The sending AR MUST increment the sequence number in the CARD Request by one each time it sends a CARD Request message.
如果当前AR的CAR表中没有完整的CAR能力信息，或者如果此类信息已过期或即将过期，AR应向相应的CAR发出AR-AR卡请求。AR-AR卡请求消息格式见第5.2.2节。AR重新启动时，AR-AR接口上的序列号从零开始。发送AR必须在每次发送卡请求消息时将卡请求中的序列号增加一。
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可以将其自身的能力（编码为属性值对并用能力容器消息参数封装）附加到已发布的AR-AR卡请求中。如果AR-AR卡请求将当前AR的能力传送给汽车，则相关的能力容器可以为上下文ID设置任何值，因为接收汽车不需要处理该值
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.
字段，因为缺少二级ID和地址子选项。此外，当前AR可以在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可以将Preferences子选项附加到AR-AR卡请求，以仅从汽车获取感兴趣的能力参数。
Upon receipt of the AR-AR CARD Reply, sent by the CAR in response to the previously sent request, the MN's current AR SHALL extract the capability information from the payload of the received message and store the received capabilities in its local CAR table. The lifetime of individual capabilities is to be set according to the lifetime indicated for each capability received. The values of the table entries' timeouts shall depend upon the nature of individual capabilities.
在收到AR-AR卡回复（由CAR响应先前发送的请求而发送）后，MN的当前AR应从接收到的消息的有效载荷中提取能力信息，并将接收到的能力存储在其本地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.
或者，如果车辆的AP或功能的配置发生动态变化，则车辆可以向全球相邻的AR发送未经请求的卡回复消息。如果当前AR从其本地CAR表中有条目的CAR接收到未经请求的卡回复消息，则当前AR检查接收到的卡回复的序列号是否比先前接收到的未经请求的卡回复消息的序列号（该消息是从同一个CAR发送的）有所增加。然后，当前AR可以根据接收到的能力更新其本地CAR表。如果添加了一辆新车，AR可能会收到不在其CAR表中的汽车或重新启动的汽车的卡片回复。在这种情况下，序列号为0。AR共享IPsec安全关联的要求（详见第6节）可确保AR从不接受来自未经验证来源的卡信息。
Upon receipt of an AR-AR CARD Request, a CAR shall extract the sending AR's capabilities, if the sending AR has included its capabilities. The CAR SHALL store the received capabilities in its CAR table and set the timer for individual capabilities appropriately. The values of the table entries' timeouts depend on the nature of capabilities in the AR-AR CARD Reply message. The CAR must include the same sequence number in the AR-AR CARD Reply Message as that received in the AR-AR CARD Request Message. The AR-AR CARD Reply shall include the CAR's capabilities as list of attribute-value pairs in the Capability Container message parameter. If the sending AR has appended an optional Preferences sub-option, the CAR MAY perform capability filtering and send back only those capabilities of interest to the requesting AR, identified according to the
收到AR-AR卡请求后，CAR应提取发送AR的能力（如果发送AR已包括其能力）。轿厢应将接收到的能力存储在轿厢表中，并适当设置各个能力的计时器。表项的超时值取决于AR-AR卡回复消息中功能的性质。汽车在AR-AR卡回复信息中必须包含与AR-AR卡请求信息中接收到的序列号相同的序列号。AR-AR卡回复应包括CAR的能力，作为能力容器消息参数中的属性值对列表。如果发送AR附加了可选的首选项子选项，则汽车可执行能力过滤，并仅将根据所述参数识别的那些感兴趣的能力发送回请求AR
Preferences sub-option. Because the AR-AR CARD Reply is based on a previously received AR-AR CARD Request, the CAR MUST set the U-flag of the AR-AR CARD Reply to 0.
首选项子选项。由于AR-AR卡回复基于之前收到的AR-AR卡请求，因此汽车必须将AR-AR卡回复的U标志设置为0。
Optionally, the CAR MAY send an unsolicited CARD Reply message to globally adjacent ARs if one or more of its capability parameters change. Each unsolicited CARD Reply message should have as destination address the adjacent AR's unicast address and must have the U-flag set. Consecutive unsolicited CARD Reply messages MUST have the sequence number incremented accordingly, starting with 0 when the AR boots.
或者，如果车辆的一个或多个性能参数发生变化，车辆可以向全球相邻的AR发送一个非请求的卡回复消息。每个未经请求的卡回复消息的目的地址应为相邻AR的单播地址，并且必须设置U标志。连续的未经请求的卡片回复消息的序列号必须相应增加，AR引导时从0开始。
CARD supports another mode of CAR information distribution, in which the capabilities are piggybacked on fast handover protocol messages. To allow MNs and ARs appending the ICMP-option type CARD Request and CARD Reply (Section 5.1.2) to the ICMP-type Fast Mobile IPv6 [Kood03] signaling messages, the MN and AR should know about the signaling peer's capability for CARD protocol message piggybacking. This requires dynamic discovery of piggybacking capability using the P-flag in the MN-AR CARD Request and the MN-AR CARD Reply message, as well as in the Capability Container message parameter. The format of these messages and parameters is described in Section 5.1.
该卡支持另一种方式的车辆信息分发，在这种方式中，这些功能依靠快速切换协议消息。为了允许MNs和AR将ICMP选项类型的卡请求和卡回复（第5.1.2节）附加到ICMP类型的快速移动IPv6[Kood03]信令消息，MN和AR应了解信令对等方的卡协议消息承载能力。这需要使用MN-AR卡请求和MN-AR卡回复消息中的P标志以及capability Container消息参数动态发现搭载能力。第5.1节描述了这些消息和参数的格式。
The MN sends the very first CARD Request to its current AR using the ICMP-type CARD main header for transport, as described in Section 4.2.1. If the MN supports CARD-protocol message piggybacking, the P-flag in this very first CARD Request message is set. On receipt of the CARD Request message, the current AR learns about the MN's piggybacking capability. To indicate its piggybacking capability, the AR sets the P-flag in the CARD Reply message. If the AR does not support piggybacking, all subsequent CARD-protocol messages between the MN and the AR are sent stand-alone, using the CARD main header. If both nodes (the MN and its current AR) support CARD-protocol message piggybacking, subsequent CARD protocol messages can be conveyed as an option via the Fast Mobile IPv6 Router Solicitation for Proxy (RtSolPr) and Proxy Router Advertisement (PrRtAdv) messages. During the CARD process, an MN learns about CARs' piggybacking capability at the discovery phase, as the Capability Container (described in Section 5.1.3.4) also carries a P-flag. This allows the MN to perform CARD protocol message piggybacking immediately after a handover to a selected CAR, assuming that this CAR supports CARD protocol piggybacking.
MN使用ICMP类型卡主报头将第一个卡请求发送到其当前AR进行传输，如第4.2.1节所述。如果MN支持卡协议消息搭载，则设置第一个卡请求消息中的P标志。收到卡请求消息后，当前AR了解MN的搭载能力。为了指示其搭载能力，AR在卡回复消息中设置P标志。如果AR不支持搭载，则MN和AR之间的所有后续卡协议消息将使用卡主标头独立发送。如果两个节点（MN及其当前AR）都支持卡协议消息搭载，则后续卡协议消息可以作为一种选项通过快速移动IPv6路由器代理请求（RtSolPr）和代理路由器广告（PrRtAdv）消息进行传输。在CARD过程中，MN在发现阶段了解CARs的搭载能力，因为能力容器（如第5.1.3.4节所述）也带有P标志。这允许MN在切换到所选车辆后立即执行卡协议消息搭载，假设该车辆支持卡协议搭载。
If a MN prefers the reverse address translation function of the Fast Mobile IPv6 protocol, it can use CARD protocol message piggybacking to retrieve only the CARs' capability information. To indicate that
如果MN更喜欢快速移动IPv6协议的反向地址转换功能，它可以使用卡协议消息搭载来仅检索汽车的能力信息。表明
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.
不需要反向地址转换，背载卡请求消息必须设置A标志。这将导致当前AR仅附加功能容器子选项。要将作为卡回复消息参数发送的功能容器与相应CAR的IP地址相关联，必须将单个功能容器的上下文ID用作索引，指向PrRtAdv消息选项中的关联IP地址。单个功能容器的上下文ID由MN的当前AR适当设置。关于如何将单个上下文ID值与PrRtAdv消息的特定IP地址选项关联的详细信息不在本文档的范围内。
The MN-AR interface uses ICMP for transport. Because ICMP messages are limited to a single packet, and because ICMP contains no provisions for retransmitting packets if signaling is lost, the CARD protocol incorporates provisions for improving transport performance on the MN-AR interface. MNs SHOULD limit the amount of information requested in a single ICMP packet, as ICMP has no provision for fragmentation above the IP level.
MN-AR接口使用ICMP进行传输。由于ICMP消息仅限于一个数据包，并且由于ICMP不包含在信令丢失时重新传输数据包的规定，因此卡协议包含了改进MN-AR接口传输性能的规定。MNs应限制单个ICMP数据包中请求的信息量，因为ICMP没有提供IP级别以上的碎片。
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类型的快速移动IPv6[Kood03]传输时，MNs和ARs使用实验性ICMP类型的主报头[Ke04]。MN-AR接口必须实现并应使用卡ICMP类型标头进行传输。如果可用，MN-AR接口可使用ICMP类型的快速移动IPv6[Kood03]进行传输（第4.4节）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+- - - -
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+- - - -
IP Fields:
IP字段：
Source Address: An IP address assigned to the sending interface.
源地址：分配给发送接口的IP地址。
Destination Address: An IP address assigned to the receiving interface.
目标地址：分配给接收接口的IP地址。
Hop Limit: 255
跃点限制：255
ICMP Fields:
ICMP字段：
Type: Experimental Mobility type (assigned by IANA for IPv4 and IPv6, see [Ke04]).
类型：实验移动类型（由IANA为IPv4和IPv6分配，请参见[Ke04]）。
Code: 0
代码：0
Checksum: The ICMP checksum.
校验和：ICMP校验和。
Subtype: Experimental Mobility subtype for CARD; see [Ke04].
子类型：CARD的实验移动子类型；见[Ke04]。
Reserved: This field is currently unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
保留：此字段当前未使用。发送方必须将其初始化为零，接收方必须忽略它。
Valid Options:
有效选项：
CARD Request: The CARD Request allows entities to request CARD-specific information from ARs. To support processing of the CARD Request message on the receiver side, further sub-options may be carried, serving as input to the reverse address translation function and/or capability discovery function.
卡请求：卡请求允许实体从ARs请求特定于卡的信息。为了支持在接收器侧处理卡请求消息，可以携带进一步的子选项，用作反向地址转换功能和/或能力发现功能的输入。
CARD Reply: The CARD Reply carries parameters, previously requested with a CARD Request, back to the sender of the CARD Request.
卡片回复：卡片回复将先前通过卡片请求请求的参数返回给卡片请求的发送者。
Valid Sub-Options:
有效子选项：
Support level is indicated in parentheses.
支撑水平用括号表示。
Layer-2 ID (mandatory): The Layer-2 ID sub-option [5.1.3.1] carries information about the type of an access point as well as the Layer-2 address of the access point associated with the CAR whose IP address and capability information is to be resolved.
第2层ID（强制性）：第2层ID子选项[5.1.3.1]包含有关接入点类型的信息，以及与要解析其IP地址和能力信息的车辆相关联的接入点的第2层地址。
Capability Container (mandatory): The Capability Container sub-option carries information about a single CAR's capabilities. The format of this sub-option is described in Section 5.1.3.4.
能力容器（必需）：能力容器子选项包含有关单个汽车能力的信息。第5.1.3.4节描述了该子选项的格式。
Address (mandatory): The Address sub-option carries information on an individual CAR's resolved IP address. The format of the Address sub-option is described in Section 5.1.3.5.
Address（必填）：Address子选项包含有关单个车辆解析IP地址的信息。地址子选项的格式见第5.1.3.5节。
Trusted Anchor (mandatory): The Trusted Anchor sub-option carries the name of a trusted anchor for which the MN has a certificate. The format of the Trusted Anchor sub-option is described in Section 5.1.3.6.
Trusted Anchor（必需）：Trusted Anchor子选项携带MN具有证书的受信任锚的名称。第5.1.3.6节描述了可信锚子选项的格式。
Router Certificate (mandatory): The Router Certificate sub-option carries one certificate in the path for the current AR or for a CAR. The chain includes certificates starting at a trusted anchor, which the AR shares in common with the MN, to the router itself. The format of the Router Certificate sub-option is described in Section 5.1.3.7.
路由器证书（必需）：路由器证书子选项在当前AR或车辆路径中携带一个证书。该链包括从AR与MN共享的可信锚点开始到路由器本身的证书。路由器证书子选项的格式见第5.1.3.7节。
Preferences (optional): The Preferences sub-option carries information about attributes of interest to the requesting entity. Attributes are encoded according to the AVP encoding rule, which is described in Section 5.1.4. For proper settings of AVP Code and Data field, see Section 5.1.3.2. This sub-option is used only if optional capability pre-filtering is performed on ARs, and it provides only capabilities of interest to a requesting MN.
首选项（可选）：首选项子选项包含请求实体感兴趣的属性的信息。属性根据第5.1.4节中描述的AVP编码规则进行编码。有关AVP代码和数据字段的正确设置，请参见第5.1.3.2节。此子选项仅在对AR执行可选功能预筛选时使用，并且它仅提供请求MN感兴趣的功能。
Requirements (optional): The Requirements sub-option carries information about attribute-value pairs required for pre-filtering of CARs on the MN's current AR. This parameter conveys MN specific attribute-value pairs to allow the MN's current AR to send only information about CARs of interest back to the requesting MN. CARs are filtered on ARs according to the CARs' capability parameters and given policy or threshold, as encoded in the Requirements sub-
需求（可选）：需求子选项携带有关MN当前AR上车辆预过滤所需的属性值对的信息。此参数传递MN特定属性值对，以允许MN当前AR仅向请求MN发送有关感兴趣车辆的信息。根据CARs的能力参数和给定的策略或阈值，在ARs上对CARs进行过滤，如需求子系统中所编码-
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.
选项属性值对根据第5.1.4节中描述的AVP编码规则进行编码。第5.1.3.3节描述了要求子选项的AVP代码和数据字段的正确设置规则。
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.
无法引发响应的卡请求将被重新传输。初始重新传输发生在卡请求重试等待期之后。必须以指数增长的等待间隔（每次等待时间加倍）进行重新传输。应重新传输卡请求，直到获得响应（可能是错误）或出现卡重试最大秒数。ARs必须在CARD_RETRY_MAX秒后丢弃具有相同序列号的任何卡请求。如果卡回复跨越多条ICMP消息，则必须在每条消息中使用相同的序列号。
MNs that retransmit a CARD Request use the same CARD sequence number. This allows the AR to cache its reply to the original request and then to send it again, should a duplicate request arrive. This cached information should only be held for a maximum of CARD_RETRY_MAX seconds after receipt of the request. Sequence numbers SHOULD be chosen randomly. Random sequence numbers avoid duplicates if MNs restart frequently and simplify sequence-number maintenance on both the MN and AR when MNs frequently appear and disappear due to movement between CARs.
重新传输卡请求的MN使用相同的卡序列号。这允许AR缓存其对原始请求的回复，然后在重复请求到达时再次发送。在收到请求后，此缓存信息最多只能保留CARD_RETRY_MAX秒。序列号应随机选择。如果MNs频繁重启，则随机序列号可避免重复，并且当MNs由于车辆之间的移动而频繁出现和消失时，可简化MN和AR上的序列号维护。
All options are of the following form:
所有选项均采用以下形式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Vers.| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Vers.| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Type: 8-bit identifier of the type of option, assigned by IANA. See [Ke04] for CARD Request and CARD Reply values.
类型：选项类型的8位标识符，由IANA分配。有关卡请求和卡回复值，请参见[Ke04]。
Length: 8-bit unsigned integer. The length of the option, including the type and length fields in units of 8 octets. The value 0 is invalid.
长度：8位无符号整数。选项的长度，包括以8个八位字节为单位的类型和长度字段。值0无效。
Vers.: 3-bit version code. For this specification, Vers.=1.
版本：3位版本代码。对于本规范，版本=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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Vers.|P|C|A|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Fields:
领域：
Type: Assigned by IANA for IPv4 and IPv6; see [Ke04].
类型：由IANA为IPv4和IPv6分配；见[Ke04]。
Length: The length of the option in units of 8 octets, including the type and length fields as well as sub-options.
长度：以8个八位字节为单位的选项长度，包括类型和长度字段以及子选项。
Vers.: 3-bit version code. For this specification, Vers.=1.
版本：3位版本代码。对于本规范，版本=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.
Flags:P-flag：表示卡请求消息发送方的卡协议消息承载能力。正确使用该标志的说明见本文件第4.4节。
C-flag: Indicates that the requesting entity is also interested in associated CARs' capabilities. If the MN wants the AR to append CARs' capability parameters to the CARD Reply in addition to address information, the MN must set this flag.
C标志：表示请求实体也对相关车辆的能力感兴趣。如果MN希望AR除了地址信息之外，还将CARs的能力参数附加到卡回复中，MN必须设置此标志。
A-flag: Indicates that the requesting entity does NOT want the receiver of this message to perform reverse address translation. This flag is set if CARD protocol messages are piggybacked with a protocol that performs reverse address translation. For details, refer to Section 4.4 of this document.
A标志：表示请求实体不希望此消息的接收方执行反向地址转换。如果卡协议消息由执行反向地址转换的协议承载，则设置此标志。有关详细信息，请参阅本文件第4.4节。
T-flag: Indicates that the requesting entity is interested in obtaining all certificates from the responder. This flag is only valid on the AR-AR interface.
T-flag：表示请求实体有兴趣从响应方获取所有证书。此标志仅在AR-AR接口上有效。
The flag combination A=1 and C=0 is invalid, and the flag T=1 is invalid on the MN-AR interface. The AR MUST discard an invalid message and log an appropriate error message.
在MN-AR接口上，标志组合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子选项-首选项子选项-需求子选项-可信锚子选项
To ensure that requirements on boundary alignment are met, individual sub-options MUST meet the 64-bit boundary alignment requirements respectively. This will ensure that the entire CARD Request option meets the 8n alignment constraint.
为确保满足边界对齐要求，各个子选项必须分别满足64位边界对齐要求。这将确保整个卡请求选项满足8n对齐约束。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Vers.|P|U|L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Vers.|P|U|L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Fields:
领域：
Type: Assigned by IANA for IPv4 and IPv6 [Ke04].
类型：由IANA为IPv4和IPv6分配[Ke04]。
Length: The length of the option in units of 8 octets, including the type and length fields as well as sub-options.
长度：以8个八位字节为单位的选项长度，包括类型和长度字段以及子选项。
Vers.: 3-bit version code. For this specification, Vers.=1.
版本：3位版本代码。对于本规范，版本=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.
Flags:P-flag：表示卡回复报文发送方的卡协议报文承载能力。正确使用该标志的说明见本文件第4.4节。
U-flag: Indicates an unsolicited CARD Reply. This flag is only valid on the AR-AR interface.
U标志：表示未经请求的卡片回复。此标志仅在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消息回复中的最后一条消息，则设置此标志。此标志仅在MN-AR接口上有效。
The flag U=1 on an AR-MN message is invalid. An invalid message should be discarded and an appropriate error message logged.
AR-MN消息上的标志U=1无效。应丢弃无效消息，并记录相应的错误消息。
Reserved: Initialized to zero, ignored on receipt.
保留：初始化为零，收到时忽略。
Sequence Number: Allows requests to be correlated with replies.
序列号：允许请求与答复关联。
Valid Sub-Options:
有效子选项：
- L2 ID sub-option - Capability Container sub-option - Address sub-option - Router Certificate sub-option
- L2 ID子选项-能力容器子选项-地址子选项-路由器证书子选项
To ensure requirements on boundary alignment are met, individual sub-options MUST meet 64-bit boundary alignment requirements respectively. This will ensure that the entire CARD Request option meets the 8n alignment constraint.
为确保满足边界对齐要求，各个子选项必须分别满足64位边界对齐要求。这将确保整个卡请求选项满足8n对齐约束。
All sub-options are of the following form:
所有子选项的形式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Sub-Option Data . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Sub-Option Data . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type: 8-bit identifier of the type of option. The sub-options defined in this document are listed in the table below. The table also indicates on which interfaces the sub-option is valid.
子选项类型：选项类型的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
Description Type Interface
| | / \
| | MN-AR AR-AR
---------------------------------------------------------------
L2 ID 0x01 x
Address 0x02 x
Capability Container 0x03 x x
Preferences 0x04 x x
Requirements 0x05 x
Trusted Anchor 0x06 x
Router Certificate 0x07 x x
Sub-Option-Length: 8-bit unsigned integer indicating the length of the sub-option, including the sub-option type and sub-option length fields. Sub-option lengths are in units of 8 octets, aligned on a 64-bit boundary. Sub-options that are shorter are padded with null octets; the extent of the padding is determined by the sub-option contents.
子选项长度：8位无符号整数，指示子选项的长度，包括子选项类型和子选项长度字段。子选项长度以8个八位字节为单位，在64位边界上对齐。较短的子选项用空八位字节填充；填充的范围由子选项内容决定。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Context-ID | Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-Type | L2 ID . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Sub-Option Type: 0x01
子选项类型：0x01
Sub-Option Length: Length of the sub-option.
子选项长度：子选项的长度。
Context-ID: Associates the L2 ID, IP address and other parameters that belong to the same AR IP address but are encoded in separate sub-options.
上下文ID：关联L2 ID、IP地址和属于相同AR IP地址但编码在单独子选项中的其他参数。
Status Code: This field allows ARs to inform a requesting entity about processing results for a particular L2 ID. The L2 ID sub-option MUST be sent back to the requesting entity with a CARD Reply message.
状态代码：此字段允许ARs将特定L2 ID的处理结果通知请求实体。L2 ID子选项必须与卡回复消息一起发送回请求实体。
The following status codes are specified:
指定了以下状态代码：
0x00: NONE - This value MUST be set when the L2 ID is included in a CARD Request.
0x00:无-当卡请求中包含L2 ID时，必须设置此值。
0x01: CANDIDATE - MUST be set in a CARD Reply when a L2 ID sub-option is included with information about candidate APs' L2 IDs. Candidate L2 IDs are sent if the CARD Request did not include a specific L2 ID for resolution. If CANDIDATE is set, the AR MUST set the Context-ID field of individual parameters to a value that allows associated L2 ID, address, and capability information to be matched on the receiver side.
0x01：候选-当L2 ID子选项包含候选AP的L2 ID信息时，必须在卡片回复中设置。如果卡请求未包含用于解析的特定L2 ID，则发送候选L2 ID。如果设置了候选者，AR必须将各个参数的上下文ID字段设置为允许在接收方匹配相关L2 ID、地址和能力信息的值。
0x02: MATCH - MUST be set in the CARD Reply to identify that this L2 ID matches previously resolved CAR information for a different L2 ID. If MATCH is set, the AR sets the Context-ID in the L2-ID sub-option to identify the matching previously resolved L2 ID.
0x02：匹配-必须在卡回复中设置，以标识此L2 ID与以前解析的车辆信息匹配不同的L2 ID。如果设置了匹配，AR将在L2-ID子选项中设置上下文ID，以标识匹配的以前解析的L2 ID。
0x03: RESOLVER ERROR - MUST be set in the CARD Reply if the L2 ID cannot be resolved. The AR sets this value for the Status Code in the returned L2 ID sub-option.
0x03:解析程序错误-如果无法解析L2 ID，则必须在卡回复中设置。AR在返回的L2 ID子选项中为状态代码设置此值。
L2 type: Indicates the interface type. Allocated by IANA [Ke04].
L2类型：表示接口类型。由IANA分配[Ke04]。
L2 ID: The variable length Layer-2 identifier of an individual CAR's access point. The length without padding is determined by the L2 type.
L2 ID：单个车辆接入点的可变长度第2层标识符。无填充的长度由L2类型决定。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Preferences
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Preferences
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type: 0x04
子选项类型：0x04
Sub-Option Length: Length of the sub-option.
子选项长度：子选项的长度。
Preferences: List of capability attribute values (see Section 5.1.4).
首选项：能力属性值列表（见第5.1.4节）。
Only ATTRIBUTE (AVP Code; see Section 5.1.4) fields MUST be present and set for individual capabilities, which are of interest to the requesting entity. The LIFETIME and VALUE (Data) indicator will not be processed and can be omitted. The AVP LENGTH indicator is also not present, as the preferences are indicated only with a list of 16-bit encoded ATTRIBUTE fields. If 64-bit boundary alignment requirements cannot be met with the list of ATTRIBUTE values, padding the missing 16-bit MUST be done with an ATTRIBUTE value of 0x0000. An ATTRIBUTE code of 0x0 is reserved so that the end of the ATTRIBUTE code list can be determined when an ATTRIBUTE value of 0x0 is read.
只有属性（AVP代码；见第5.1.4节）字段必须存在，并为请求实体感兴趣的单个功能设置。寿命和值（数据）指示器将不被处理，可以省略。AVP长度指示器也不存在，因为首选项仅用16位编码属性字段列表表示。如果属性值列表无法满足64位边界对齐要求，则必须使用属性值0x0000填充缺少的16位。保留属性代码0x0，以便在读取属性值0x0时确定属性代码列表的结尾。
The use of the Preferences sub-option is optional and is for optimization purposes.
首选项子选项的使用是可选的，用于优化目的。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type: 0x05
子选项类型：0x05
Sub-Option Length: Length of the sub-option.
子选项长度：子选项的长度。
Requirements: AVP-encoded requirements (see Section 5.1.4)
要求：AVP编码要求（见第5.1.4节）
AVPs MUST be encoded according to the rule described in Section 5.1.4. Both the ATTRIBUTE (AVP Code) and VALUE (Data) fields MUST be present and set appropriately. The end of the Requirements list can be determined when an ATTRIBUTE value of 0x0 is read.
AVP必须根据第5.1.4节所述规则进行编码。属性（AVP代码）和值（数据）字段都必须存在并适当设置。当读取属性值0x0时，可以确定需求列表的结尾。
The use of the Requirements sub-option is optional and is for optimization purposes.
“需求”子选项的使用是可选的，用于优化目的。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Context-ID |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVPs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Context-ID |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVPs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Sub-Option Type: 0x03
子选项类型：0x03
Sub-Option Length: Length of the sub-option.
子选项长度：子选项的长度。
Context-ID: Associates the L2 ID, IP address, and other parameters that belong to the same AR IP address but are encoded in separate sub-options.
上下文ID：关联L2 ID、IP地址和属于相同AR IP地址但编码在单独子选项中的其他参数。
Flags: P-flag: Indicates piggybacking capability of the CAR whose capabilities are conveyed in this Capability Container. This flag allows an MN to know after a CARD process whether a selected new AR can perform piggybacking.
标志：P-flag：表示车辆的搭载能力，其能力在此能力容器中传输。此标志允许MN在卡处理后知道所选新AR是否可以执行搭载。
Reserved: Initialized to zero, ignored on receipt.
保留：初始化为零，收到时忽略。
AVPs: AVPs are a method of encapsulating capability information relevant for the CARD protocol. See Section 5.1.4 for the AVP encoding rule and list parsing.
AVPs：AVPs是封装与卡协议相关的功能信息的方法。AVP编码规则和列表解析见第5.1.4节。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Context-ID | Address Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Context-ID | Address Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -
Sub-Option Type: 0x02
子选项类型：0x02
Sub-Option Length: Length of the sub-option. For IPv4, the length is 1 (8 octets); for IPv6 the length is 3 (24 octets).
子选项长度：子选项的长度。对于IPv4，长度为1（8个八位字节）；对于IPv6，长度为3（24个八位字节）。
Context-ID: Associates the L2 ID, IP address, and other parameters that belong to the same AR IP address but are encoded in separate sub-options.
上下文ID：关联L2 ID、IP地址和属于相同AR IP地址但编码在单独子选项中的其他参数。
Address Type: Indicates the type of the address.
地址类型：表示地址的类型。
0x01 IPv4 0x02 IPv6
0x01 IPv4 0x02 IPv6
Address: The Candidate Access Router's IP address.
地址：候选访问路由器的IP地址。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trusted Anchor Name
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trusted Anchor Name
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -
Sub-Option Type: 0x06
子选项类型：0x06
Sub-Option Length: Length of the sub-option.
子选项长度：子选项的长度。
Reserved: Initialized to zero, ignored on receipt.
保留：初始化为零，收到时忽略。
Component: A 2 octet unsigned integer field set to 65,535 if the sender desires to retrieve all the certificates in the certification path. Otherwise, it is set to the component identifier corresponding to the certificate that the receiver wants to retrieve.
组件：如果发送方希望检索证书路径中的所有证书，则将2个八位无符号整数字段设置为65535。否则，它被设置为与接收方想要检索的证书相对应的组件标识符。
Trusted Anchor Name: DER encoding for the X.501 name of certification path component(see [Arkko04] for more detail on certification path component name encoding).
可信锚点名称：证书路径组件的X.501名称的DER编码（有关证书路径组件名称编码的更多详细信息，请参阅[Arkko04]）。
A CARD Request message containing Trusted Anchor sub-options MUST NOT contain any other sub-options, except for a single L2 ID sub-option identifying the AP of interest.
包含受信任锚子选项的卡请求消息不得包含任何其他子选项，但标识感兴趣AP的单个L2 ID子选项除外。
Trusted anchor sub-options SHOULD be retransmitted for individual components not received within CARD_REQUEST_RETRY seconds, rather than retransmitting a request for the whole list. Subsequent retransmissions SHOULD take into account any received options and only request those that have not been received.
对于卡请求重试秒内未收到的单个组件，应重新传输受信任的锚子选项，而不是重新传输整个列表的请求。后续重新传输应考虑任何已接收的选项，并仅请求尚未接收的选项。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Context-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All Components | Component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Certificate... |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type: 0x07
子选项类型：0x07
Sub-Option Length: Length of the sub-option.
子选项长度：子选项的长度。
Context-ID: Associates the L2 ID, IP address and other parameters that belong to the same AR IP address but are encoded in separate sub-options.
上下文ID：关联L2 ID、IP地址和属于相同AR IP地址但编码在单独子选项中的其他参数。
Reserved: Initialized to zero, ignored on receipt.
保留：初始化为零，收到时忽略。
All Components: 2 octet unsigned integer giving the total number of certificates in the certification path.
所有组件：2个八位无符号整数，表示证书路径中的证书总数。
Component: 2 octet unsigned integer giving the location of this certificate in the certification path.
组件：2个八位无符号整数，表示此证书在证书路径中的位置。
Certificate: Variable-length field containing the X.509v3 router certificate encoded in ASN.1 (see [Arkko04] for more detail on a certificate profile that includes encoding).
证书：可变长度字段，包含ASN.1中编码的X.509v3路由器证书（有关包含编码的证书配置文件的更多详细信息，请参阅[Arkko04]）。
Padding: Variable-length field making the option length a multiple of 8, beginning after the ASN.1 encoding of the certificate and continuing to the end of the option, as specified by the Length field.
填充：可变长度字段，使选项长度为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.
包含路由器证书子选项的卡回复不得包含多个此类子选项，并且卡回复必须包含具有链且上下文ID字段设置为非零值且没有其他子选项的路由器的匹配L2 ID子选项和路由器地址子选项。应忽略卡片回复中包含的任何其他子选项。如果回复跨越多条ICMP消息，则发送的第一条消息中必须包含L2 ID子选项和路由器地址子选项，并且所有消息中路由器证书子选项中的上下文ID字段必须设置为与L2 ID和地址子选项中相同的值。应答AR应该对返回的证书路径进行排序，以便路径中信任锚之后的证书是第一个发送的证书，以便允许立即验证。不应发送信任锚证书本身。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code | AVP Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Lifetime | Data . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code | AVP Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Lifetime | Data . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
AVP Code: Identifies the attribute uniquely. The AVP Code 0x0000 is reserved and MUST NOT be assigned to a capability.
AVP代码：唯一标识属性。AVP代码0x0000是保留的，不得分配给功能。
AVP Length: The 2 octet AVP length field indicates the number of octets in this AVP, including the AVP Code, AVP Length, Reserved, Lifetime, and Data fields.
AVP长度：2个八位字节的AVP长度字段表示此AVP中的八位字节数，包括AVP代码、AVP长度、保留、生存期和数据字段。
Reserved: Initialized to zero, ignored on receipt.
保留：初始化为零，收到时忽略。
Lifetime: Specifies the lifetime of the encoded capability in seconds. In the case of a static capability, the Lifetime field MUST be set to the maximum value (0xffff), which indicates that the lifetime of this capability parameter never expires. A lifetime value of 0x0000 deletes a capability entry.
生存期：以秒为单位指定编码功能的生存期。对于静态功能，必须将Lifetime字段设置为最大值（0xffff），这表示此功能参数的生存期永不过期。生存期值0x0000将删除功能项。
Data: This variable-length field has the Value of the capability attribute encoded.
数据：此可变长度字段具有编码的能力属性值。
Because an AVP Code of 0x0 is reserved, it can be used by the sub-option list parsing to determine when the end of a list of Capabilities has been reached and where the sub-option padding starts. AVPs themselves are not zero padded.
因为保留了0x0的AVP代码，所以子选项列表解析可以使用它来确定何时到达功能列表的末尾以及子选项填充的开始位置。AVP本身不是零填充的。
Note: This document provides no detailed information on how to encode the individual capability attribute values, which is to be encoded in the Data field. Details on the interpretation of individual capability parameters are out of the scope of this document.
注：本文件未提供如何编码单个能力属性值的详细信息，这些属性值将在数据字段中编码。有关单个能力参数解释的详细信息不在本文件范围内。
Because the types of access networks in which CARD might be useful are not currently deployed or, if they have been deployed, have not been extensively measured, it is difficult to know whether congestion will be a problem for inter-router CARD. Part of the research task in preparing CARD for consideration as a candidate for possible standardization is to quantify this issue. However, in order to avoid potential interference with production applications (should a prototype CARD deployment involve running over the public Internet), it seems prudent to recommend a default transport protocol that accommodates congestion.
由于卡可能有用的接入网络类型目前尚未部署，或者，如果已经部署，尚未进行广泛测量，因此很难知道拥塞是否会成为路由器间卡的问题。准备卡片作为可能的标准化候选的研究任务的一部分是量化这个问题。然而，为了避免对生产应用程序的潜在干扰（如果原型卡部署涉及在公共互联网上运行），建议使用默认传输协议以适应拥塞似乎是谨慎的。
This suggests that implementations of CARD MUST support and that prototype deployments of CARD SHOULD use the Stream Control Transport Protocol (SCTP) [Stew00] as the transport protocol between routers, especially if deployment over the public Internet is contemplated. SCTP supports congestion control, fragmentation, and partial retransmission based on a programmable retransmission timer. SCTP also supports many advanced and complex features, such as multiple streams and multiple IP addresses for failover, that are not necessary for experimental implementation and prototype deployment of CARD. The use of these SCTP features for CARD is not recommended at this time.
这表明卡的实现必须支持，并且卡的原型部署应使用流控制传输协议（SCTP）[Stud00]作为路由器之间的传输协议，特别是如果考虑在公共互联网上部署。SCTP支持基于可编程重传计时器的拥塞控制、分段和部分重传。SCTP还支持许多高级和复杂的功能，例如用于故障切换的多个流和多个IP地址，这些功能对于卡的实验性实现和原型部署是不必要的。目前不建议对卡使用这些SCTP功能。
The SCTP Payload Data Chunk carries the CARD messages. CARD messages on the inter-router interface consist of just the CARD Request or CARD Reply options. The User Data part of each SCTP message contains the CARD option for the message type. For instance, a CARD Reply message is constructed by including the CARD Reply option and all the appropriate sub-options within the User Data part of an SCTP message.
SCTP有效负载数据块承载卡消息。路由器间接口上的卡消息仅包括卡请求或卡回复选项。每个SCTP消息的用户数据部分包含消息类型的卡选项。例如，通过在SCTP消息的用户数据部分中包括卡回复选项和所有适当的子选项来构造卡回复消息。
A single stream is used for CARD with in-sequence delivery of SCTP messages. Each message, unless fragmented, corresponds to a single CARD query or response. Unsolicited CARD Reply messages can also be sent to peers to notify them of changes in network configuration or capabilities. A single stream provides simplicity. Use of multiple streams to prevent head-of-line blocking is for future study. Since timeliness is not an issue with inter-router CARD, and since there being more than one CARD transaction between two routers active at any one time is unlikely, having ordered delivery simplifies the implementation. The Payload Protocol Identifier in the SCTP header is 'CARD'. CARD uses the Seamoby SCTP port number [Ke04].
单流用于按顺序传递SCTP消息的卡。每一条消息，除非是零碎的，都对应于一个卡片查询或响应。还可以向对等方发送未经请求的卡回复消息，以通知他们网络配置或功能的更改。单个流提供了简单性。使用多个流来防止线头阻塞是为了将来的研究。由于路由器间卡的及时性不是问题，而且两个路由器之间在任何时候都不可能有一个以上的卡交易，因此订购交付简化了实现。SCTP标头中的有效负载协议标识符为“卡”。卡使用Seamoby SCTP端口号[Ke04]。
The format of Payload Data Chunk taken from [Stew00] is shown in the following diagram.
从[Stew00]获取的有效负载数据块的格式如下图所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'U' bit The Unordered bit. MUST be set to 0 (zero). 'B' bit The Beginning fragment bit. See [Stew00].
“U”位是无序位。必须设置为0（零）。'B'位是起始片段位。见[00]。
'E' bit The Ending fragment bit. See [Stew00].
“E”位是结束片段位。见[00]。
TSN Transmission Sequence Number. See [Stew00].
TSN传输序列号。见[00]。
Stream Identifier S Identifies the CARD stream.
流标识符S标识卡流。
Stream Sequence Number n Sequence number. See [Stew00].
流序列号n序列号。见[00]。
Payload Protocol Identifier Set to 'CARD'.
有效负载协议标识符设置为“卡”。
User Data Contains the CARD message.
用户数据包含卡消息。
In order to avoid generating congestion on startup, ARs MUST wait a random amount of time between 0 and CARD_STARTUP_WAIT seconds upon reboot before sending an AR-AR CARD Request to one of its CARs. An AR that receives a CARD Request from another AR that is not in its CAR table MUST NOT solicit the AR but rather MUST wait until the AR sends an unsolicited CARD Reply advertising the AR's information. An AR that is starting up MUST send unsolicited CARD Replies to all its CARs to make sure that their CAR tables are properly populated.
为了避免在启动时产生拥塞，ARs必须在重新启动时等待0到CARD_startup_wait秒之间的随机时间，然后再向其一辆汽车发送AR-AR卡请求。从不在其CAR表中的另一个AR接收卡请求的AR不得请求该AR，而是必须等待AR发送一个非请求的卡回复，宣传AR的信息。正在启动的AR必须向其所有汽车发送未经请求的卡片回复，以确保其汽车表已正确填充。
The frequency of unsolicited CARD Reply messages MUST be strictly limited to CARD_MIN_UPDATE_INTERVAL, in order to avoid overwhelming CARs with traffic. ARs are free to discard messages that arrive more frequently.
未经请求的卡片回复信息的频率必须严格限制在卡片更新间隔内，以避免车辆拥挤。AR可以随意丢弃更频繁到达的消息。
If a CARD deployment will never run over the public Internet, and if it is known that congestion is not a problem in the access network, alternative transport protocols MAY be appropriate vehicles for experimentation. Implementations of CARD MAY support UDP for such purposes. In that case, the researcher MUST be careful to accommodate good Internet transport protocol engineering practices, such as using retransmits with exponential backoff. In addition, whether SCTP is an appropriate transport protocol for all inter-router CARD operations is an open research question. Investigation of this issue (for example, to determine whether a lighter-weight protocol might be more appropriate than SCTP) may be of interest to some researchers.
如果卡部署永远不会在公共互联网上运行，并且如果已知接入网络中的拥塞不是问题，则替代传输协议可能是合适的实验工具。出于这种目的，卡的实现可能支持UDP。在这种情况下，研究人员必须小心适应良好的Internet传输协议工程实践，例如使用具有指数退避的重传。此外，SCTP是否是所有路由器间卡操作的合适传输协议是一个开放的研究问题。对这一问题的调查（例如，确定较轻的协议是否比SCTP更合适）可能引起一些研究人员的兴趣。
The AR-AR interface MUST insert the CARD Request option and CARD Reply option directly into the body of the SCTP User Data field. The sequence number for the CARD Request on the AR-AR interface MUST be initialized to zero when the AR reboots, and MUST be incremented every time a CARD Request message is sent. The replying AR MUST include a sequence number from the CARD Request in the CARD Reply. If an unsolicited CARD Reply is sent, the sending AR MUST increment the sequence number. Sequentially increasing sequence numbers allows the receiving AR to determine whether the information has already been received.
AR-AR接口必须将卡请求选项和卡回复选项直接插入SCTP用户数据字段的正文中。AR-AR接口上的卡请求序列号必须在AR重新启动时初始化为零，并且必须在每次发送卡请求消息时递增。回复AR必须在卡片回复中包含卡片请求的序列号。如果发送了未经请求的卡片回复，则发送AR必须增加序列号。顺序增加序列号允许接收AR确定信息是否已经被接收。
On the AR-AR interface, the Capability Container parameter is used to convey capabilities between ARs. Optionally, the Preferences parameter can be used for capability pre-filtering during the inter-AR capability discovery procedure. Payload types and encoding rules are the same as those described for the respective sub-option types in Section 5.1 for the MN-AR interface. The same TLV-encoded format is used to attach the options as payload to the protocol main header. Additionally, an AR can set the T flag in the CARD Request header in
在AR-AR接口上，Capability Container参数用于在AR之间传递能力。可选地，Preferences参数可用于AR间能力发现过程中的能力预过滤。有效负载类型和编码规则与第5.1节中针对MN-AR接口的相应子选项类型所述的相同。使用相同的TLV编码格式将选项作为有效负载附加到协议主标头。此外，AR可以在中的卡请求标头中设置T标志
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.
为了获得汽车的证书。第5.1.3节中的子选项说明包括AR-AR界面上禁止的标志设置信息。
The veracity of the CARD protocol depends on the ability of an AR to obtain accurate information about geographically neighboring ARs, and to provide accurate information about its own APs and capabilities to other ARs. The CARD protocol described in the body of this document does not contain any support for determining the AR-to-AP mapping or capabilities, either for a specific AR or for a CAR. Therefore, methods for determining the accuracy of the information exchanged between ARs are out of scope for the base CARD protocol. The appendices of this document describe procedures for discovering the identities of the geographically adjacent ARs and APs (including capabilities) and discuss relevant security considerations. Alternatively, this information could be statically configured into the AR.
卡协议的准确性取决于AR获取地理上相邻AR的准确信息以及向其他AR提供其自身AP和能力的准确信息的能力。本文档正文中描述的卡协议不包含任何用于确定特定AR或CAR的AR到AP映射或能力的支持。因此，用于确定AR之间交换的信息的准确性的方法超出了基本卡协议的范围。本文件的附录描述了发现地理上相邻的ARs和AP身份（包括能力）的程序，并讨论了相关的安全注意事项。或者，可以将此信息静态配置到AR中。
CARD contains support allowing ARs to exchange capability information. If this protocol is not protected from modification, a malicious attacker can modify the information. Also, if the information is delivered in plain text, a third party can read it.
该卡支持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之间的卡消息进行身份验证。如果需要，这些信息还应加密以保护信息的隐私。例如，如果运营商网络中两个AR之间的通信量穿越公共互联网，则可能需要保密。
Two ARs engaging in the CARD protocol MUST use IKE [HarCar98] to negotiate an IPsec ESP security association for message authentication. If confidentiality is desired, the two ARs MUST additionally negotiate an ESP security association for encryption. Replay protection SHOULD also be enabled with IKE. To protect CARD protocol messages between ARs, IPsec ESP [AtKe98] MUST be used with a non-null integrity protection and origin authentication algorithm and SHOULD be used with a non-null encryption algorithm for protecting the confidentiality of the CARD information.
参与卡协议的两个AR必须使用IKE[HarCar98]协商IPsec ESP安全关联以进行消息身份验证。如果需要保密，两个AR还必须协商ESP安全关联以进行加密。还应使用IKE启用重播保护。为了保护ARs之间的卡协议消息，IPsec ESP[AtKe98]必须与非空完整性保护和原始身份验证算法一起使用，并且应与非空加密算法一起使用，以保护卡信息的机密性。
An AR can provide the certificates for its CARs if the certificates are available. The AR requests certificates from its CARs by setting the T flag in the CARD Request message. All certificates are sent.
AR可以为其车辆提供证书（如果证书可用）。AR通过在卡请求消息中设置T标志从其车辆请求证书。所有证书均已发送。
If CARD is used to exchange information between different administrative domains, additional security policy issues may apply. Such issues are out of the scope of this document. Use of CARD between administrative domains is not recommended at this time, until the policy issues involved are more thoroughly understood.
如果卡用于在不同的管理域之间交换信息，则可能会出现其他安全策略问题。此类问题不在本文件范围内。目前不建议在管理域之间使用CARD，直到更彻底地了解所涉及的策略问题。
A malicious node can send bogus CARD Reply messages to MNs by masquerading as the AR. The MN MUST authenticate the CARD Reply messages from the AR. Since establishing an IPSec security association between the MN and AR is likely to be a performance issue, IKE is not an appropriate mechanism for setting up the security association. Instead, the SEND security association is used [Arkko04]. ARs MUST include a SEND Signature Option on CARD Reply messages. The format of the signature option is the same for both IPv4 and IPv6 CARD, though SEND itself is only defined for IPv6. A Mobile IPv4 ICMP Foreign Agent Advertisement option type code for the SEND signature option [Ke04] has been allocated.
恶意节点可以通过伪装为AR向MNs发送虚假的卡回复消息。MN必须验证来自AR的卡回复消息。由于在MN和AR之间建立IPSec安全关联可能是一个性能问题，因此IKE不是建立安全关联的适当机制。而是使用发送安全关联[Arkko04]。ARs必须在卡回复消息中包含发送签名选项。签名选项的格式对于IPv4和IPv6卡都是相同的，尽管发送本身仅为IPv6定义。已为发送签名选项[Ke04]分配移动IPv4 ICMP外部代理播发选项类型代码。
No authentication is required for CARD Requests since CARD information is provided by the AR to optimize link access. In contrast, CARD Reply authentication is required because a bogus AR could provide the MN with CARD information that would lead the MN to handover to a bogus router, which could steal traffic or propagate a denial of service attack on the MN. The asymmetry of the authentication requirement is the same as that involving Router Advertisements in IPv6 router discovery [Arkko04].
由于AR提供卡信息以优化链路访问，因此无需对卡请求进行身份验证。相反，需要卡回复认证，因为伪AR可以向MN提供卡信息，从而导致MN切换到伪路由器，而伪路由器可以窃取流量或在MN上传播拒绝服务攻击。身份验证要求的不对称性与IPv6路由器发现中涉及路由器广告的不对称性相同[Arkko04]。
Since CARD is a discovery protocol, confidentiality is not generally necessary on the MN-AR interface. In specific cases where different network operators share the same access network infrastructure, network operators may want to hide information about operator-specific capabilities for business reasons. The base CARD protocol contains no support for such cases. However, should such a case arise in the future, an AVP for an encrypted capability can be defined at that time.
由于CARD是一种发现协议，所以MN-AR接口通常不需要保密。在不同网络运营商共享相同接入网络基础设施的特定情况下，网络运营商可能出于业务原因希望隐藏有关运营商特定功能的信息。基本卡协议不支持此类情况。然而，如果将来出现这种情况，可以在那时定义加密功能的AVP。
Because SEND is only available in IPv6, the procedures for obtaining certificates differ depending on whether CARD is used with IPv4 or IPv6. In IPv6, when the MN receives a CARD reply with signature from an AR for which it does not have a certificate, it SHOULD use SEND DCS/DCA to obtain the AR's certificate chain. ARs MUST be configured with a certification path for this purpose, and MNs MUST be configured with a set of certificates for shared trusted anchors to allow verification of the AR certificates. An MN may not necessarily
由于SEND仅在IPv6中可用，因此获取证书的过程因卡与IPv4还是IPv6一起使用而有所不同。在IPv6中，当MN从没有证书的AR接收到带有签名的卡片回复时，它应该使用SEND DCS/DCA来获取AR的证书链。为此，必须为AR配置一个证书路径，并且必须为MNs配置一组用于共享受信任锚的证书，以允许验证AR证书。MN不一定
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），所以CGA支持对于卡是可选的。发送规范[Arkko04]中描述了ARs的证书配置文件。
In IPv4, there is no DCS/DCA message for obtaining the certificate. If the MN does not have a certificate for the AR, the MN sends a CARD Request message containing the L2 ID of its current AP and one Trusted Anchor sub-option (Section 5.1.3.6) for each shared trusted anchor for which the MN has a certificate, to obtain the certification path for the current AR. The Component field of the Trusted Anchor sub-option is set to 65535 to indicate that the entire certification path is needed. No other options should be included in the request. The AR replies by sending a CARD Reply containing the L2 ID sub-option sent in the request, an Address sub-option for itself, and a Router Certificate sub-option (Section 5.1.3.7) containing one certificate in its certification path that matches one of the requested trust anchors, and no other sub-options, setting the Context-ID of all sub-options to match. The All Components field is set to the path length, and the Component field is set to the number of this component in the path. If the path is longer than one certificate, the AR sends the L2 ID sub-option and the Address sub-option in the first certificate and the other certificates in separate ICMP messages, due to the limitation on ICMP message length, with the same Context-ID set on each Route Certificate sub-option, and with the Component field properly set. The router SHOULD NOT send the trusted anchor's certificate and SHOULD send certificates in order from the certificate after the trusted anchor. If the trusted anchor option does not match any certificate, the AR returns the Trusted Anchor sub-options in the reply. The MN SHOULD immediately conduct a Certificate Revocation List (CRL) check on any certificates obtained through CARD certificate exchange, to make sure that the certificates are still valid.
在IPv4中，没有用于获取证书的DCS/DCA消息。如果MN没有AR的证书，MN将发送一条卡请求消息，其中包含其当前AP的L2 ID和MN拥有证书的每个共享可信锚的一个可信锚子选项（第5.1.3.6节），获取当前AR的认证路径。Trusted Anchor子选项的组件字段设置为65535，以指示需要整个认证路径。请求中不应包含其他选项。AR通过发送包含请求中发送的L2 ID子选项、自身的地址子选项和路由器证书子选项（第5.1.3.7节）的卡回复进行回复，路由器证书子选项在其证书路径中包含一个证书，该证书与请求的信任锚之一匹配，且没有其他子选项，将所有子选项的上下文ID设置为匹配。“所有零部件”字段设置为路径长度，“零部件”字段设置为路径中该零部件的编号。如果路径长于一个证书，则由于ICMP消息长度的限制，AR在第一个证书中发送L2 ID子选项和地址子选项，并在单独的ICMP消息中发送其他证书，在每个路由证书子选项上设置相同的上下文ID，并正确设置组件字段。路由器不应发送受信任的锚的证书，而应在受信任的锚之后按顺序从证书发送证书。如果trusted anchor选项与任何证书都不匹配，AR将在回复中返回trusted anchor子选项。MN应立即对通过卡证书交换获得的任何证书进行证书撤销列表（CRL）检查，以确保证书仍然有效。
Certification paths for CARs may be fetched in advance of handover by requesting them as part of the CARD protocol. In that case, the MN includes Trusted Anchor sub-options in the CARD request along with the L2 ID sub-option for the AP for which the CAR certificate is desired, and the AR replies as above, except that the L2 ID, address, and certificates are for the CAR instead of for the AR itself. This allows the MN to skip the DCS/DCA or CARD certificate exchange when it moves to a new router.
车辆的认证路径可以在车辆移交之前通过请求获取，作为卡协议的一部分。在这种情况下，MN在卡请求中包括可信锚子选项以及用于需要CAR证书的AP的L2 ID子选项，并且AR如上所述回复，除了L2 ID、地址和证书用于CAR而不是AR本身。这允许MN在移动到新路由器时跳过DCS/DCA或卡证书交换。
Because the amount of space in an ICMP message is limited, the router certification paths SHOULD be kept short.
由于ICMP消息中的空间量有限，路由器认证路径应保持较短。
An AR can be overwhelmed with CARD Request messages. The AR SHOULD implement a rate-limiting policy so that it does not send or process more than a certain number of messages per period. The following is a suggested rate limiting policy. If the number of CARD messages exceeds CARD_REQUEST_RATE, the AR SHOULD begin to drop messages randomly until the rate is reduced. MNs SHOULD avoid sending messages more frequently than CARD_REQUEST_RATE. ARs SHOULD also avoid sending unsolicited CARD Replies or CARD Requests more frequently than CARD_MIN_UPDATE_INTERVAL, but, in this case, the existence of an IPsec security association ensures that messages from unknown entities will be discarded immediately during IPsec processing.
AR可能会被卡请求消息淹没。AR应实施速率限制策略，以便在每个周期内发送或处理的消息数量不超过一定数量。以下是建议的利率限制政策。如果卡消息数超过卡请求速率，AR应开始随机丢弃消息，直到速率降低。MNs应避免发送超过卡请求率的消息。ARs还应避免发送未经请求的卡片回复或卡片请求的频率高于卡片更新间隔，但在这种情况下，IPsec安全关联的存在可确保在IPsec处理期间立即丢弃来自未知实体的消息。
MNs MUST discard CARD Replies for which there is no outstanding CARD Request, as indicated by the sequence number.
MNs必须放弃没有未完成的卡请求的卡回复，如序列号所示。
To protect against replay attacks on the AR-AR interface, ARs SHOULD enable replay protection when negotiating the IPsec security association using IKE.
为了防止AR-AR接口上的重播攻击，ARs应在使用IKE协商IPsec安全关联时启用重播保护。
On the MN-AR interface, the MN MUST discard any CARD Replies for which there is no outstanding request, as determined by the sequence number. For ARs, an attacker can replay a previous request from an MN, but the attack is without serious consequence because the MN ignores the reply in any case.
在MN-AR接口上，MN必须丢弃由序列号确定的没有未完成请求的任何卡片回复。对于ARs，攻击者可以重播来自MN的先前请求，但攻击不会造成严重后果，因为MN在任何情况下都会忽略回复。
Constant Section Default Value Meaning
--------------------------------------------------------------------
CARD_REQUEST_RETRY 5.1.1 2 seconds Wait interval before
initial retransmit
on MN-AR interface.
Constant Section Default Value Meaning
--------------------------------------------------------------------
CARD_REQUEST_RETRY 5.1.1 2 seconds Wait interval before
initial retransmit
on MN-AR interface.
CARD_RETRY_MAX 5.1.1 15 seconds Give up on retry on MN-AR interface.
卡重试最多5.1.1 15秒在MN-AR接口上放弃重试。
CARD_STARTUP_WAIT 5.2.1 1-3 seconds Maximum startup wait for an AR before performing AR-AR CARD.
卡\u启动\u等待5.2.1在执行AR-AR卡之前，AR的最大启动等待时间为1-3秒。
CARD_MIN_UPDATE_INTERVAL 5.2.1 60 seconds Minimum AR-AR update interval.
卡最小更新间隔5.2.1最小AR-AR更新间隔60秒。
CARD_REQUEST_RATE 6.5 2 requests/ Maximum number of sec. messages before AR institutes rate limiting.
卡请求率6.5 2请求/最大秒数。AR设置速率限制之前的消息。
See [Ke04] for instructions on IANA allocation.
有关IANA分配的说明，请参见[Ke04]。
[Brad97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Brad97]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[Stew00] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[AtKe98] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[AtKe98]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[HarCar98] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[HarCar98]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[Arkko04] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[Arkko04]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[Ke04] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[Ke04]Kempf，J.“Seamoby和实验移动协议IANA分配说明”，RFC 4065，2005年7月。
[TKCK02] Trossen, D., Krishanmurthi, G. Chaskar, H., Kempf, J., "Issues in candidate access router discovery for seamless IP-level handoffs", Work in Progress.
[TKCK02]Trossen，D.，Krishanmurthi，G.Chaskar，H.，Kempf，J.，“无缝IP级切换的候选接入路由器发现问题”，正在进行中。
[MaKo03] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[MaKo03]Way，J.和M.Kojo，“机动性相关术语”，RFC 3753，2004年6月。
[Kood03] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[Kood03]Koodli，R.，Ed.，“移动IPv6的快速切换”，RFC 4068，2005年7月。
[Funa02] Funato, D., et al., "Geographically Adjacent Access Router Discovery Protocol", Work in Progress.
[Funa02]Funato，D.，等，“地理相邻接入路由器发现协议”，正在进行中。
[Tros03] Trossen, D., et al., "A Dynamic Protocol for Candidate Access-Router Discovery", Work in Progress.
[Tros03]Trossen，D.，等人，“候选接入路由器发现的动态协议”，正在进行中。
[ShGi00] Shim, E. and R. Gitlin, "Fast Handoff Using Neighbor Information", Work in Progress.
[ShGi00]Shim，E.和R.Gitlin，“使用邻居信息快速切换”，工作正在进行中。
[Malk03] El Malki, K., et al., "Low Latency Handoffs in Mobile IPv4", Work in Progress.
[Malk03]El Malki，K.等人，“移动IPv4中的低延迟切换”，正在进行中。
The authors would like to thank Vijay Devarapalli (Nokia) and Henrik Petander (Helsinki University of Technology) for formally reviewing the protocol specification document and providing valuable comments and input for technical discussions. The authors would also like to thank James Kempf for reviewing and for providing a lot of valuable comments and editing help.
作者要感谢Vijay Devarapalli（诺基亚）和Henrik Petander（赫尔辛基工业大学）正式审查协议规范文件，并提供宝贵的意见和输入进行技术讨论。作者还要感谢James Kempf的评论，并提供了许多有价值的评论和编辑帮助。
The authors would like to thank (in alphabetical order) Dirk Trossen, Govind Krishnamurthi, James Kempf, Madjid Nakhjiri, Pete McCann, Rajeev Koodli, Robert C. Chalmers, and other members of the Seamoby WG for their valuable comments on the previous versions of the document, as well as for the general CARD-related discussion and feedback. In addition, the authors would like to thank Erik Nordmark for providing valuable insight about the piggybacking of CARD options upon Fast Mobile IPv6 messages.
作者要感谢（按字母顺序排列）德克·特罗森、戈文德·克里希那穆提、詹姆斯·坎普夫、马吉德·纳赫吉里、皮特·麦肯、拉吉夫·库德利、罗伯特·查默斯和Seamoby工作组的其他成员对文件先前版本的宝贵意见，以及与卡片相关的一般性讨论和反馈。此外，作者还想感谢Erik Nordmark，他为快速移动IPv6消息上的卡选项提供了宝贵的见解。
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.
本附录提供了有关访问路由器中反向地址映射的两种可选车表维护方案的信息。这些方案取代了CAR表中AP L2 ID到CAR IP地址映射的静态配置。有关这些机制的详细信息不在本文件范围内。本附录的目的仅是提供本文件所述的卡协议灵活扩展的基本概念。
Appendix A.1. Centralized Approach Using a Server Functional Entity
附录A.1。使用服务器功能实体的集中式方法
The centralized approach performs CARD over the MN-AR interface as described in Section 4 of this document. Additionally, the centralized approach introduces a new entity, the CARD server, to assist the current AR in performing reverse address translation. The centralized approach requires that neighboring ARs register with the CARD server to populate the reverse address translation table. The registration of AR addresses with the CARD server is performed prior to initiation of any reverse address translation request.
如本文件第4节所述，集中式方法通过MN-AR接口执行CARD。此外，集中式方法引入了一个新实体，即卡服务器，以帮助当前AR执行反向地址转换。集中式方法要求相邻的AR向卡服务器注册，以填充反向地址转换表。在发起任何反向地址转换请求之前，向卡服务器注册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说明了集中卡操作的典型场景。在此示例中，AR已提前向卡服务器注册了其地址信息。当MN在L2扫描期间发现AP的L2 ID时，它将一个或多个L2 ID传递给其当前AR，AR将其解析为AR的IP地址。为此，AR首先检查其CAR表中的映射信息是否在本地可用。如果不是，MN的当前AR查询具有L2 ID的卡服务器。作为响应，卡服务器将汽车的IP地址返回到当前AR。然后，当前AR直接联系相应的汽车并与其执行能力发现。然后，当前AR将汽车的IP地址和相关功能传递给MN。然后，当前AR将解析的IP地址存储在其本地CAR表中。集中式卡协议操作引入了附加的信令消息，这些消息在MN的当前AR和卡服务器之间交换。AR和卡服务器功能之间的信令消息以前面的标识符“AR服务器”显示，表示相关接口。
An initial idea of performing reverse address translation using a centralized server is described in [Funa02].
[Funa02]中描述了使用集中式服务器执行反向地址转换的最初想法。
+----------+
+------------>| CARD |<-------------+
|+------------| Server |-------------+|
|| +----------+ ||
|| ||
|| ~~~~~~~~~~~ ||
(3)AR-Server||(4)AR-Server{ } ||(0) CARD
CARD || CARD { } ||Reg Req/
Request || Reply { IP Cloud } | Reply
|| { } ||
|| { } ||
|V ~~~~~~~~~~~ V|
+---------+ (5)AR-AR CARD Request +-----+-----+
| Current |------------------------->| CAR | CAR |
| AR |<-------------------------| 1 | 2 |
+---------+ (6)AR-AR CARD Reply +-----+-----+
^ | | |
(2)MN-AR | |(7)MN-AR | |
CARD | | CARD | |
Request| V Reply +---+ +---+
+--------------+ (1) AP1 L2 ID +--|AP1| |AP2|
| Mobile |<---------------------+ +---+ +---+
| Node |<--------------------------------+
+--------------+ (1) AP2 L2 ID
+----------+
+------------>| CARD |<-------------+
|+------------| Server |-------------+|
|| +----------+ ||
|| ||
|| ~~~~~~~~~~~ ||
(3)AR-Server||(4)AR-Server{ } ||(0) CARD
CARD || CARD { } ||Reg Req/
Request || Reply { IP Cloud } | Reply
|| { } ||
|| { } ||
|V ~~~~~~~~~~~ V|
+---------+ (5)AR-AR CARD Request +-----+-----+
| Current |------------------------->| CAR | CAR |
| AR |<-------------------------| 1 | 2 |
+---------+ (6)AR-AR CARD Reply +-----+-----+
^ | | |
(2)MN-AR | |(7)MN-AR | |
CARD | | CARD | |
Request| V Reply +---+ +---+
+--------------+ (1) AP1 L2 ID +--|AP1| |AP2|
| Mobile |<---------------------+ +---+ +---+
| Node |<--------------------------------+
+--------------+ (1) AP2 L2 ID
Figure A.1: Centralized Approach for L2-L3 Mapping
图A.1：L2-L3映射的集中方法
Appendix A.2. Decentralized Approach Using Mobile Terminals' Handover
附录A.2。基于移动终端切换的分散方法
This approach performs CARD over the MN-AR interface as described in Section 4. However, it employs one additional message, called the Router Identity message, over the MN-AR interface to enable ARs to learn about the reverse address translation tables of their neighboring ARs, without being dependent on any centralized server.
这种方法在MN-AR接口上执行CARD，如第4节所述。然而，它在MN-AR接口上使用一条称为路由器标识消息的附加消息，以使AR能够了解其相邻AR的反向地址转换表，而不依赖于任何集中式服务器。
In this approach, CAR identities in the CAR table of an AR are maintained as soft state. The entries for CARs are removed from the CAR table if they are not refreshed before the timeout period expires and are created or refreshed according to the following mechanism.
在这种方法中，AR的CAR表中的CAR身份保持为软状态。如果在超时期限到期之前未刷新CAR的条目，则会从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
分散方法背后的关键思想是，使用在两个AR之间发生的MN的实际切换作为输入，引导和维护作为彼此邻居的两个AR之间的关联。任何两个相邻AR之间的第一次切换用作引导切换以调用发现过程，随后的切换用于刷新相邻AR之间的关联。自举切换后，MNs可以执行
CARD and thus seamless handover using the CAR information. This idea was presented in [ShGi00] and [Tros03].
使用汽车信息进行无缝交接。这一想法在[ShGi00]和[Tros03]中提出。
Maintenance of the CAR table is done by using an additional option for the CARD protocol operation performed between an MN and its current AR. This message serves as Router Identity message.
通过使用MN与其当前AR之间执行的卡协议操作的附加选项来维护CAR表。此消息用作路由器标识消息。
Upon the completion of an inter-AR handover, the MN SHOULD send a Router Identity message to its current AR. This message contains the identity (IP address) of the previous AR (pAR), and can be sent as a specific sub-option in the MN-AR CARD Request message. It SHOULD be acknowledged with the MN-AR CARD Reply. The Router Identity message enables the MN's current AR to learn that the pAR (still) has an AP whose coverage overlaps with one of the APs of the current AR, and vice versa. With this information, the MN's current AR can create or refresh an entry for the pAR as its neighbor. If handover is no longer possible between two ARs, the associated entries eventually timeout and are removed from each AR's CAR table.
AR间切换完成后，MN应向其当前AR发送路由器标识消息。该消息包含前一AR（pAR）的标识（IP地址），并可作为MN-AR卡请求消息中的特定子选项发送。应通过MN-AR卡回复予以确认。路由器身份消息使MN的当前AR知道PAR（STAR）具有AP，其覆盖与当前AR的AP中的一个重叠，反之亦然。利用这些信息，MN的当前AR可以创建或刷新PAR作为其邻居的条目。如果两个AR之间无法再进行切换，则相关条目最终会超时，并从每个AR的CAR表中删除。
Prior to trusting the MN's report, however, the current AR may perform a number of checks to ensure the validity of the received information. One simple method is to verify the accuracy of the Router Identity message by sending an AR-AR CARD Request message to the pAR. The AR-AR CARD Request includes the identity of the MN. Upon receiving this message, the pAR verifies that the MN was indeed attached to it during a reasonable past interval and responds to the current AR. In this way, each handover of a MN results in a bi-directional discovery process between the two participating ARs.
然而，在信任MN的报告之前，当前AR可以执行许多检查以确保所接收信息的有效性。一种简单的方法是通过向ARR发送AR-AR卡请求消息来验证路由器标识消息的准确性。AR-AR卡请求包括MN的标识。当接收到该消息时，PAR验证MN确实在合理的过去间隔中与它连接，并以这种方式响应当前的AR.，MN的每次切换导致在两个参与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创建或刷新适用于其本地轿厢表中的PAR的条目。在前一种情况下，使用AR-AR卡请求和AR-AR卡应答协议消息的当前AR和PAR交换能力。创建新条目时，ARs必须交换其反向地址转换表。此时，它们可以交换其他功能，也可以将交换推迟到稍后某个正在进行切换的MN执行第4节所述的卡时进行。在后一种（刷新）情况下，ARs可以交换能力或将交换推迟到另一个MN进行切换的稍后时间。
Finally, note that in a handover-based protocol, a first handover between a pAR and an MN's current AR cannot use CARD, as this handover bootstraps the CAR table. However, in the long term, such a handover will only amount to a small fraction of total successful handover between the two ARs. Also, if the MN engaging in such a first handover is running a non-delay sensitive application at the time of handover, the user may not even realize its impact.
最后，请注意，在基于切换的协议中，PAR和MN的当前AR之间的第一次切换不能使用卡，因为该切换引导轿厢表。然而，从长远来看，这样的切换只占两个AR之间总成功切换的一小部分。此外，如果参与这种第一切换的MN在切换时正在运行非延迟敏感应用程序，则用户甚至可能没有意识到其影响。
This section provides two examples of application scenarios for CARD protocol operation. One scenario describes a CARD protocol operation in a Mobile IPv6 (MIPv6) network, providing access to the infrastructure via wireless LAN Access Points and associated Access Routers. A second scenario describes CARD protocol operation in a Mobile IPv6-enabled network, which has enhanced support for fast handover integrated (Fast Mobile IPv6), also providing wireless LAN access to the infrastructure.
本节提供了卡协议操作的两个应用场景示例。一个场景描述了移动IPv6（MIPv6）网络中的卡协议操作，通过无线LAN接入点和相关接入路由器提供对基础设施的访问。第二个场景描述了支持移动IPv6的网络中的卡协议操作，该网络增强了对集成快速切换（快速移动IPv6）的支持，还提供了对基础设施的无线LAN访问。
This application scenario assumes a moving MN having access to the infrastructure through wireless LAN (IEEE802.11) APs. Mobility management is performed using the Mobile IPv6 protocol. The following figure illustrates the assumed access network design.
此应用场景假设移动MN通过无线LAN（IEEE802.11）AP访问基础设施。使用移动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 | - - ->>>- - - ->>>
+-----+
-----------------------------
/ \ +----+
| NETWORK |---| HA |
\ / +----+
-----------------------------
| |
+-----+ +-----+
| AR1 |---------+ | AR2 |
+-----+ | +-----+
| subnet 1 | |subnet 2
+-----+ +-----+ +-----+
| AP1 | | AP2 | | AP3 |
+-----+ +-----+ +-----+
^ ^ ^
\
\
\
v
+-----+
| MN | - - ->>>- - - ->>>
+-----+
Figure B.1: Assumed Network Topology
图B.1：假定的网络拓扑
A Mobile IPv6 Home Agent (HA) maintains location information for the MN in its binding cache. In Figure B.1, the MN holds a care-of address for the subnet 1, supported by AR1. As the MN moves, the MN's current environment offers two further wireless LAN APs with increasing link-quality as candidate APs for a handover. To
移动IPv6归属代理（HA）在其绑定缓存中维护MN的位置信息。在图B.1中，MN持有AR1支持的子网1的转交地址。随着MN的移动，MN的当前环境提供了另外两个链路质量提高的无线LAN ap作为切换的候选ap。到
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).
为了便于决策，在决策过程中会考虑与AR相关的参数。AR相关参数可以是，例如，可用QoS资源或AR支持的接入技术的类型。为了了解这些候选AR的能力和相关IP地址信息，MN执行卡。这需要检索有关候选AP的L2 ID的信息。此外，检索相关联的链路质量参数以确定接近的ap是否是切换的合格候选。如果AP2和AP3是合适的候选AP，则MN使用L2 ID子选项将两个L2 ID（AP2和AP3）封装到卡请求消息中，并将消息发送到其当前AR（AR1）。
AR1 resolves each L2 ID listed in L2 ID options to the associated IP address of the respective CAR, making use of its local CAR table. According to the environment illustrated in Figure B.1, the associated AR IP address of the candidate AP2 will be the same as the MN is currently attached to, which is AR1. The corresponding IP address of the candidate AR, to which AP3 is connected, is the address of AR2. IP addresses of the MN's CARs are now known to AR1, which retrieves the CARs' capabilities from the CAR table. Assuming that it has valid entries for respective capability parameters to refresh dynamic capabilities, whose associated lifetimes in AR1's CAR table have expired, AR1 performs Inter-AR CARD for capability discovery. Since capability information for AR1 is known to AR1, a respective Inter-AR CARD Request is sent only to AR2. In response, AR2 sends a CARD Reply message back to AR1, encapsulating the requested capability parameters with the signaling message in a Capability Container sub-option.
AR1利用其本地CAR表，将L2 ID选项中列出的每个L2 ID解析为相应CAR的关联IP地址。根据图B.1中所示的环境，候选AP2的关联AR IP地址将与MN当前连接到的地址相同，即AR1。AP3连接到的候选AR的对应IP地址是AR2的地址。MN的CARs的IP地址现在为AR1所知，AR1从CAR表中检索CARs的功能。假设AR1具有用于刷新动态功能的相应功能参数的有效条目，且AR1的CAR表中的相关生存期已过期，AR1将执行AR卡间功能发现。由于AR1知道AR1的能力信息，因此仅向AR2发送相应的AR卡间请求。作为响应，AR2将卡回复消息发送回AR1，将请求的能力参数与信令消息封装在能力容器子选项中。
Next, AR1 sends its own capabilities and the dynamically discovered ones of AR2 back to the MN via a CARD Reply message. Furthermore, AR1 stores the capability parameters of AR2 with the associated lifetimes in its local CAR table.
接下来，AR1通过卡回复消息将其自身的能力和动态发现的AR2能力发送回MN。此外，AR1在其本地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.
在接收到卡应答消息后，MN执行目标AR选择，同时考虑AR1和AR2的能力参数以及相关ap的链路质量参数。如果选择的AP是AP2，则不需要执行IP切换。如果选择了AP3和关联的AR2，则MN需要根据移动IPv6协议操作执行IP切换。
Figure B.2 illustrates the signaling flow of the previously described application scenario of CARD within a Mobile IPv6-enabled network.
图B.2说明了前面描述的移动IPv6支持网络中的卡应用场景的信令流。
MN AP1 AR1 AP2 AP3 AR2
| | | | | |
| connected | | | | |
0-------------0-------0 | | |
| | | | | |
| | | | | |
| | | |
| <~~~~~~~~~L2-SCAN (AP2)~~~~~| | |
| <~~~~~~~~~L2-SCAN (AP3)~~~~~~~~~~~~~~~~~| |
| | | |
| (MN-AR) CARD Req | | | |
|-------------------->| (AR-AR) CARD Req |
| | |---------------------------------------->|
| | | (AR-AR) CARD Repl |
| (MN-AR) CARD Repl |<----------------------------------------|
|<--------------------| | | |
| | | | | |
[target AR | | | | |
selection] | | | | |
| | | | | |
// // // // // //
[either...] | | | | |
| | | | | |
|-------- L2 attach --------->| | |
| | | | | |
| connected | | | |
0---------------------0-------0 | |
| | | | | |
// // // // // //
[... or] | | | | |
| | | | | |
|--------------- L2 attach -------------->| |
| | | | | |
| connected | | | |
0-----------------------------------------0---------------------0
| | | | | |
| | |
| MIPv6 Binding Update to the HA | |
|------------------------------------------------ - - - > |
| | | | | |
MN AP1 AR1 AP2 AP3 AR2
| | | | | |
| connected | | | | |
0-------------0-------0 | | |
| | | | | |
| | | | | |
| | | |
| <~~~~~~~~~L2-SCAN (AP2)~~~~~| | |
| <~~~~~~~~~L2-SCAN (AP3)~~~~~~~~~~~~~~~~~| |
| | | |
| (MN-AR) CARD Req | | | |
|-------------------->| (AR-AR) CARD Req |
| | |---------------------------------------->|
| | | (AR-AR) CARD Repl |
| (MN-AR) CARD Repl |<----------------------------------------|
|<--------------------| | | |
| | | | | |
[target AR | | | | |
selection] | | | | |
| | | | | |
// // // // // //
[either...] | | | | |
| | | | | |
|-------- L2 attach --------->| | |
| | | | | |
| connected | | | |
0---------------------0-------0 | |
| | | | | |
// // // // // //
[... or] | | | | |
| | | | | |
|--------------- L2 attach -------------->| |
| | | | | |
| connected | | | |
0-----------------------------------------0---------------------0
| | | | | |
| | |
| MIPv6 Binding Update to the HA | |
|------------------------------------------------ - - - > |
| | | | | |
Figure B.2. CARD Protocol Operation within a Mobile IPv6-Enabled Wireless LAN Network
图B.2。支持移动IPv6的无线LAN网络中的卡协议操作
Appendix B.2. CARD Operation in a Fast Mobile IPv6 Network
附录B.2。快速移动IPv6网络中的卡操作
This application scenario assumes that ARs can perform the fast handover protocol sequence for Mobile IPv6 [Kood03]. The MN scans for new APs for handover, similar to Figure B.1. To discover the ARs (CARs), the MN attaches a MN-AR CARD Request option to the ICMP-type Fast Mobile IPv6 RtSolPr message, which is sent to the MN's current AR (pAR, previous AR).
此应用场景假设ARs可以执行移动IPv6的快速切换协议序列[Kood03]。MN扫描用于切换的新AP，类似于图B.1。为了发现AR（CARs），MN将MN-AR卡请求选项附加到ICMP类型的快速移动IPv6 RtSolPr消息，该消息被发送到MN的当前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.)
候选AP的L2 ID使用卡协议的L2 ID子选项进行封装，这允许MN将候选AP的多个L2 ID发送到其当前AR。（这可能取代快速移动IPv6协议的“新连接点链路层地址”选项。）
The pAR resolves the received list of candidate APs' L2 IDs to the IP addresses of associated CARs. The pAR checks its local CAR table to retrieve information about the CARs' capabilities. If any table entries have expired, the pAR acquires this CAR's capabilities by sending an AR-AR CARD Request to the respective CAR. The CAR replies with an AR-AR CARD Reply message, encapsulating all capabilities in a Capability Container sub-option and attaching them to the CARD Reply option. On receipt of the CARs' capability information, the pAR updates its local CAR table and forwards the address and capability information to the MN by attaching a MN-AR CARD Reply option to the Fast Mobile IPv6 PrRtAdv message. When the MN's handover is imminent, the MN selects its new AR and the associated new AP from the discovered list of CARs. According to the Fast Mobile IPv6 protocol, the MN notifies the pAR of the selected new AR with the Fast Binding Update (F-BU) message, allowing the pAR to perform a fast handover according to the Fast Mobile IPv6 protocol.
PAR将候选APS’L2 ID的接收列表解析为相关联的汽车的IP地址。PAR检查其本地汽车表，以检索有关汽车的能力的信息。如果任何表项已经过期，PAR通过向相应的汽车发送AR-AR卡请求来获取该车的能力。CAR回复AR-AR卡回复消息，将所有功能封装在功能容器子选项中，并将其附加到卡回复选项。在接收到车辆的能力信息时，PAR更新其本地轿厢表，并通过将MN-AR卡应答选项附加到快速移动IPv6 PRRTADV消息，将地址和能力信息转发到MN。当MN的切换即将到来时，MN从发现的车辆列表中选择其新AR和相关联的新AP。根据快速移动IPv6协议，MN通过快速绑定更新（FBU）消息通知所选择的新AR的PAR，允许PAR根据快速移动IPv6协议执行快速切换。
Optionally, the pAR could perform selection of an appropriate new AR on behalf of the MN after the pAR has the MN's CARs' addresses and associated capabilities available. The MN must send its requirements for the selection process to its pAR together with the MN-AR CARD Request message After the pAR has selected the MN's new AR, the address and associated capabilities of the chosen new AR are sent to the MN with the CARD Reply option in the Fast Mobile IPv6 PrRtAdv message.
可选地，PAR可以代表MN的一个合适的新AR，在PAR具有MN的汽车地址和相关的可用功能之后。在PAR选择了MN的新AR之后，MN必须将其选择过程的要求发送到其PAR以及MN-AR卡请求消息，所选择的新AR的地址和相关联的能力在快速移动IPv6 PRRTADV消息中用卡应答选项发送到MN。
Figure B.3 illustrates how CARD protocol messages and functions work with the Fast Mobile IPv6 protocol.
图B.3说明了卡协议消息和功能如何与快速移动IPv6协议一起工作。
MN pAR NAR CAR2
| | as CAR1 |
| | | |
|-------RtSolPr------>| | |
| [MN-AR CARD Req] |-- AR-AR CARD Req*->| |
| |-- AR-AR CARD Req*------------>|
| |<--AR-AR CARD Repl*------------|
| |<--AR-AR CARD Repl*-| |
|<------PrRtAdv-------| | |
| [MN-AR CARD Repl] | | |
| | | |
NAR selection | | |
|------F-BU---------->|--------HI--------->| |
| |<------HACK---------| |
| <--F-BACK--|--F-BACK--> | |
| | | |
Disconnect | | |
| forward | |
| packets===============>| |
| | | |
| | | |
Connect | | |
| | | |
RS (with FNA option)======================>| |
|<-----------RA (with NAACK option)--------| |
|<=================================== deliver packets |
| | |
MN pAR NAR CAR2
| | as CAR1 |
| | | |
|-------RtSolPr------>| | |
| [MN-AR CARD Req] |-- AR-AR CARD Req*->| |
| |-- AR-AR CARD Req*------------>|
| |<--AR-AR CARD Repl*------------|
| |<--AR-AR CARD Repl*-| |
|<------PrRtAdv-------| | |
| [MN-AR CARD Repl] | | |
| | | |
NAR selection | | |
|------F-BU---------->|--------HI--------->| |
| |<------HACK---------| |
| <--F-BACK--|--F-BACK--> | |
| | | |
Disconnect | | |
| forward | |
| packets===============>| |
| | | |
| | | |
Connect | | |
| | | |
RS (with FNA option)======================>| |
|<-----------RA (with NAACK option)--------| |
|<=================================== deliver packets |
| | |
Figure B.3. Fast Handover Protocol Sequence with CARD Protocol Options
图B.3。带卡协议选项的快速切换协议序列
* In Figure B.3, the CARD protocol interaction between the pAR and CARs is only required if the lifetime of any capability entries in the pAR's CAR table have expired. Otherwise, the pAR can respond to the requesting MN immediately after retrieving the CARs' addresses and capability information from its CAR table.
* 在图B.3中，如果PAR的CAR表中的任何能力项的寿命已经过期，则只需要PAR和CAR之间的卡协议交互。否则，PAR可以在从其汽车表中检索汽车的地址和能力信息之后立即响应请求的MN。
Authors' Addresses
作者地址
Hemant Chaskar AirTight Networks 339 N. Bernardo Avenue Mountain View, CA 94043, USA
Hemant Chaskar密闭网络339北伯纳多大道山景城，加利福尼亚州94043
EMail: hemant.chaskar@airtightnetworks.net
EMail: hemant.chaskar@airtightnetworks.net
Daichi Funato NTT DoCoMo, Inc. Communication Systems Laboratory Wireless Laboratories 3-5, Hikarinooka, Yokosuka, Kanagawa 239-8536, Japan
Daichi Funato NTT DoCoMo，Inc.通信系统实验室无线实验室3-5，日本神奈川横须贺Hikarinooka 239-8536
Phone: +81-46-840-3921
EMail: funato@mlab.yrp.nttdocomo.co.jp
Phone: +81-46-840-3921
EMail: funato@mlab.yrp.nttdocomo.co.jp
Marco Liebsch NEC Network Laboratories Kurfuersten-Anlage 36, 69115 Heidelberg, Germany
Marco Liebsch NEC网络实验室Kurfuersten Anlage 3669115德国海德堡
Phone: +49 6221-90511-46
EMail: marco.liebsch@netlab.nec.de
Phone: +49 6221-90511-46
EMail: marco.liebsch@netlab.nec.de
Eunsoo Shim Panasonic Digital Networking Laboratory Panasonic Corporation Two Research Way Princeton, NJ 08540
Eunsoo Shim松下数字网络实验室松下公司双研究路新泽西州普林斯顿08540
Phone: +1-609-734-7354
EMail: eunsoo@research.panasonic.com
Phone: +1-609-734-7354
EMail: eunsoo@research.panasonic.com
Ajoy Singh Motorola Inc 2G11, 1501 West Shure Dr. Arlington Heights, IL 60004, USA
Ajoy Singh Motorola Inc.2G11，1501美国伊利诺伊州西舒尔阿灵顿高地博士，邮编60004
Phone: +1 847-632-6941
EMail: asingh1@email.mot.com
Phone: +1 847-632-6941
EMail: asingh1@email.mot.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。