IETF Seamoby Working Group Internet Draft Marco Liebsch Category: Experimental Ajoy Singh (Editors) Hemant Chaskar Daichi Funato Eunsoo Shim draft-ietf-seamoby-card-protocol-07.txt Expires: December 2004 June 2004 Candidate Access Router Discovery Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. 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 of candidate ARs (CARs) for handover, along with their capabilities, prior to the initiation of the IP-layer handover. The act of discovery of CARs has two aspects to it: identifying the IP addresses of the CARs and finding the capabilities of those CARs. This process is called "candidate access router discovery" (CARD). At the time of IP-layer handover, that CAR, whose capabilities is 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. Liebsch and Singh (editors) Expires December 2004 [Page 1] Internet-Draft Candidate Access Router Discovery June 2004 TABLE OF CONTENTS 1. INTRODUCTION...................................................3 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........................................5 4.1 Conceptual Data Structures.................................8 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.12 5. PROTOCOL MESSAGES.............................................13 5.1 CARD Messages for the Mobile Node-Access Router Interface.13 5.2 CARD Inter-Access Router Messages.........................26 6. SECURITY CONSIDERATIONS.......................................29 6.1 Veracity of CARD Information..............................29 6.2 Security Association between AR and AR....................29 6.3 Security Association between AR and MN....................30 6.4 Router Certificate Exchange...............................30 6.5 DoS Attack................................................31 6.6 Replay Attacks............................................32 7. PROTOCOL CONSTANTS............................................32 8. IANA CONSIDERATIONS...........................................32 9. NORMATIVE REFERENCES..........................................32 10. INFORMATIVE REFERENCES.......................................33 11. AUTHORS' ADDRESSES...........................................34 12. IPR STATEMENTS...............................................34 13. COPYRIGHT NOTICE.............................................35 15. ACKNOWLEDGEMENTS.............................................35 Appendix A MAINTENANCE OF ADDRESS MAPPING TABLES IN ACCESS ROUTERS. . . . . . . . . . . . . . . . . . . 39 Appendix A.1 Centralized Approach using a Server Functional Entity. . . . . . . . . . . . . . . . . . . . . . . 39 Appendix A.2 Decentralized Approach using Mobile Terminals' Handover. . . . . . . . . . . . . . . . . . . . . . 40 Appendix B APPLICATION SCENARIOS . . . . . . . . . . . . . . . 43 Appendix B.1 CARD Operation in a Mobile IPv6 Enabled Wireless LAN Network . . . . . . . . . . . . . . . . . . . . 43 Appendix B.2 CARD Operation in a Fast Mobile IPv6 enabled network . . . . . . . . . . . . . . . . . . . . . . 46 Liebsch and Singh (editors) Expires December 2004 [Page 2] Internet-Draft Candidate Access Router Discovery June 2004 Conventions used in this document 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]. 1. INTRODUCTION IP mobility protocols, such as Mobile IP, enable mobile nodes to execute IP-level handover among access routers. Additionally, work is underway [Kood03][Malk03] to extend the mobility protocols to allow seamless IP handover. The pre-requisite for the seamless IP mobility protocols is the 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. CAR discovery involves identifying a CAR's IP address as well as the capabilities that the mobile node might use for a handover decision. There are cases when a mobile node has a choice of CARs. The mobile node chooses one based on 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 scope of this document. 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, necessary for reverse address translation. The default method is static configuration. Appendix B contains two sample scenarios for using CARD. 2. TERMINOLOGY This document uses terminology defined in [MaKo03]. In addition, the following terms are used: Access Router (AR) An IP router residing in an access network and connected to one or more APs. An AR offers IP connectivity to MNs. Liebsch and Singh (editors) Expires December 2004 [Page 3] Internet-Draft Candidate Access Router Discovery June 2004 Candidate AR (CAR) An AR to which a MN has a choice when performing IP-level handover. Capability of an AR A characteristic of the service offered by an AR that may be of interest to a MN when the AR is being considered as a handover candidate. L2 ID Identifier of an AP that uniquely identifies that AP. For example, in 802.11, this could be a MAC address of an AP. CARD Initiating Trigger 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. Access Point (AP) A wireless access point, identified by a MAC address, providing service to the wired network for wireless nodes. 3. CARD PROTOCOL FUNCTIONS The CARD protocol accomplishes the following functions. 3.1 Reverse Address Translation If a 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. 3.2 Discovery of CAR Capabilities Information about 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, while others can change with time. Definition of capabilities is out of scope of this document. Encoding rules for capabilities and the format of a capability container for capability transport are specified in Section 5. Liebsch and Singh (editors) Expires December 2004 [Page 4] Internet-Draft Candidate Access Router Discovery June 2004 4. CARD PROTOCOL OPERATION The CARD protocol is used to allow MNs resolving the L2 ID of one or more APs, which are candidates the MN may initiate a handover to, to the IP address of the associated CARs, as well as to discover these CARs' capabilities. Furthermore, the protocol allows ARs to populate and maintain their local CAR table (Section 4.1) with the capabilities of CARs. For this, the CARD protocol makes use of CARD Request and CARD Reply messages between a MN and its current AR (Section 5.1.2), and between a MN's current AR and individual CARs respectively (Section 5.2.2). To allow a MN to retrieve a CARs' address and capability information, the CARD Request and CARD Reply messages used between a 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 CARs' capability information. A CAR's capabilities are specified as a list of attribute-value pairs, which are conveyed in a Capability Container message parameter. Information about the CAR(s) and associated capabilities MAY be used by the MN to perform target access router selection during its IP handover. The current AR returns replies based on its CAR table (see Section 4.1), and returns a RESOLVER ERROR (see Section 5.1.3.1) if the request cannot be resolved. The CARD protocol also enables a 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 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. Optionally, the MN can provide its current AR with a list of capability attribute-value pairs, indicating not only the capability parameters (attributes) as required for capability pre-filtering, but also a specific value for a particular capability. This allows the MN's current AR performing 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. As an example, using the optional Preferences message parameter, a MN may indicate to its current AR that it is interested only in IEEE802.11a interface specific capability parameters, since this is Liebsch and Singh (editors) Expires December 2004 [Page 5] Internet-Draft Candidate Access Router Discovery June 2004 the only interface the MN has implemented. Hence, the MN's current AR sends back only CARs' IEEE802.11a specific capabilities. Similarly, using the optional Requirements message parameter, a MN may indicate to its current AR that it is only interested in CARs that can satisfy a given QoS constraint. Here, a MN sends the respective QoS attribute with the QoS constraint value to its current AR using the optional Requirements message parameter. The QoS constraint is denoted as an attribute-value pair and encapsulated with the Requirements message parameter, which is appended to the MN-originated CARD Request message. The Requirements message parameter may be used to indicate the cut off values of the capabilities for the desired CAR(s). Based on 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, in case no optimization with regard to capability or CAR pre-filtering is performed by the MN's current AR, the current AR MAY choose to silently ignore the optional Requirements and Preferences message parameter as received in the CARD Request message. The MN can additionally request from the AR a certificate chain 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 certificate chain. If no match is found, the AR returns the trusted anchors from the CARD Request. The MN can ask for a chain for either the current AR or for 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 router's certified key, and thereby validate signatures on CARD messages, and other messages between the MN and AR. The MN only need send the trusted anchor option if it does not have the certificate chain for the router already cached. If the mobile node has the certificate chain cached, either through preconfiguration, previous receipt of the chain from this router, or through having received the chain through a previous router, then the trusted anchor does not need to be sent. More information about certificate exchange and its use in CARD security can be found in Section 6. The CARD protocol operation, as described in this section, distinguishes signaling messages exchanged between a MN and its Liebsch and Singh (editors) Expires December 2004 [Page 6] Internet-Draft Candidate Access Router Discovery June 2004 current AR and signaling messages exchanged between ARs. Hence, description of signaling messages described in the following sections has a preceding identifier, referring to the associated interface. Messages that are exchanged between a MN and AR are designated as "MN-AR", messages between ARs are designated as "AR- AR" respectively. +--------------+ (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 Figure 1 describes the operation of the MN-AR CARD Request/Reply protocol and AR-AR CARD Request/Reply protocol. On reception 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 ID(s) to its current AR using the MN-AR CARD Request message (2m). In case 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, in case the MN has not attached any L2 ID message parameters, it 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 the IP address of the CAR(s) and, in case capability information has been requested, associated capabilities to the MN using the MN-AR CARD Reply message (3m). 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 CAR Reply message with the requested information (2a). Liebsch and Singh (editors) Expires December 2004 [Page 7] Internet-Draft Candidate Access Router Discovery June 2004 4.1 Conceptual Data Structures AR(s) SHALL maintain a 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 respectively. ARs SHOULD also keep and maintain individual CARs' capabilities in the local CAR table, taking the associated capability lifetime 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 ARs' CAR table may be implemented differently, hence 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 and so that an MN can obtain the AR's certificate chain. 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. 4.2 Mobile Node - Access Router Operation 4.2.1 Mobile Node Operation To initiate CARD, a 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 to obtain capability parameters associated with these CARs. In case 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 CARD Request MUST set the C-flag. 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. In case the MN appends multiple L2 ID sub-options to a CARD Request, the AR MUST assume each L2 ID is associated with an AP, which connects to a different CAR. Since L2 IDs, address information and capability information are transmitted with separate sub-options, Liebsch and Singh (editors) Expires December 2004 [Page 8] Internet-Draft Candidate Access Router Discovery June 2004 each sub-option carries a Context-ID, to allow matching parameters that belong together. Hence, 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 in the CARD Request message MUST always be set to NONE (0x00) by a 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. Upon receipt of the corresponding MN-AR CARD Reply message, the MN correlates the CARD Reply with appropriate CARD Request message and then processes all MN-AR CARD Reply message parameters to retrieve its CARs' address and capability information. If 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 MN reboots after sending CARD Request Message to the connected AR. Processing the Context-ID of Address sub-options allows the MN to assign the resolved IP address of a specific CAR to a L2 ID. In some cases a 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 being sent towards the MN. RESOLVER ERROR Status-Code indication: In case the MN's current AR could not resolve a particular L2 ID, this status code is returned to the 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 is an indicator that the Context-ID of this particular L2 ID sub-option has been set to the Context-ID of the associated CAR's Address and Capability Container sub-option, which is sent with this CARD Reply message. This approach avoids sending the same CAR's address and capability information multiple times with the same CARD Reply message in case two or more L2 IDs resolve to the same CAR. 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. CANDIDATE Status-Code indication: In case the MN does not append any L2 ID to the CARD, the AR sends back the L2 ID and address information of all CARs. Since the received parameters' Context-IDs cannot be correlated with a 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 Liebsch and Singh (editors) Expires December 2004 [Page 9] Internet-Draft Candidate Access Router Discovery June 2004 ID to the associated Address and the possibly received Capability Container sub-option. As described in Section 4.5, an MN can use CARD when it boots up initially 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.2.2 Current Access Router Operation Upon receipt of a MN's MN-AR CARD-Request, the connected AR SHALL resolve the requested APs' L2 ID to the IP address of the associated CAR(s). In case 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. 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 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. In case an AR cannot resolve a particular L2 ID, an L2 ID sub-option is sent back to the MN, indicating RESOLVER ERROR in the L2 ID sub-option's Status-Code field. 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. Here, the AR marks the Status-Code of individual L2 IDs as CANDIDATE, indicating to the MN, that the associated Context-ID cannot be matched with the ID of a previously sent request. In any case, the AR MUST set the Context-ID of the Address and the Capability Container sub-option to the same value of the associated L2 ID sub-option. 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 along with associated capabilities are then delivered to the MN using the MN-AR CARD Reply message. The CARs' IP address as well as the capabilities SHALL be encoded according to the format for CARD protocol message parameters as Liebsch and Singh (editors) Expires December 2004 [Page 10] Internet-Draft Candidate Access Router Discovery June 2004 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. 4.3 Current Access Router - Candidate Access Router Operation 4.3.1 Current Access Router Operation The MN's current AR MAY initiate capability exchange with CARs either when it receives a MN-AR CARD Request or when it detects that one or multiple of its local CAR table's capability entries' lifetime is about to expire. An AR SHOULD preferentially utilize its CAR table to fulfill requests rather than signaling 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. The AR SHOULD issue an AR-AR CARD Request to the respective CAR(s) 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. 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. In case 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, since there is no need for the receiving CAR to process this field due to the absence of a 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. 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. Upon receipt of the AR-AR CARD Reply, which has been 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. Liebsch and Singh (editors) Expires December 2004 [Page 11] Internet-Draft Candidate Access Router Discovery June 2004 The value of the table entries' timeout shall depend upon the nature of individual capabilities. Optionally, CARs can send unsolicited CARD Reply messages to globally adjacent ARs if the configuration of their APs or capabilities changes dynamically. In case 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 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 CARD 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. 4.3.2 Candidate Access Router Operation 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 value of the table entries' timeout depends upon 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 received in 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. In case the sending AR has appended an optional Preferences sub-option, the CAR MAY perform capability filtering and send back only these capabilities, which are of interest to the requesting AR, identified according to the Preferences sub-option. Since 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. Optionally, the CAR MAY send an unsolicited CARD Reply message to globally adjacent ARs in case one or more of its capability parameters change. The unsolicited CARD Reply messages should have as destination address the adjacent ARs' unicast address and must have the U-flag set. Consecutive unsolicited CARD Reply messages MUST have the sequence number incremented respectively, starting with 0 when the AR boots. The CAR MUST set the U-flag in unsolicited AR-AR CARD Reply messages. 4.4 CARD Protocol Message Piggybacking on the MN-AR Interface CARD supports another mode of CAR information distribution, in which the capabilities are distributed piggybacked on a fast handover Liebsch and Singh (editors) Expires December 2004 [Page 12] Internet-Draft Candidate Access Router Discovery June 2004 protocol. 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. 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. In case the MN supports CARD protocol message piggybacking, the P-flag in this very first CARD Request message is set. On reception of the CARD Request message, 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. In case 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. In case 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, a MN learns about CAR's piggybacking capability during the discovery phase, since the Capability Container, as described in Section 5.1.3.4, also carries a P-flag. This allows the MN to immediately perform CARD protocol message piggybacking after a handover to a selected CAR, assumed this CAR supports CARD protocol piggybacking. If a MN prefers the reverse address translation function of the Fast Mobile IPv6 protocol, it can use CARD protocol message piggybacking to retrieve only the CARs' capability information. To indicate that reverse address translation is not required, the piggybacked CARD Request message MUST have the A-flag set. These 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. 5. PROTOCOL MESSAGES 5.1 CARD Messages for the Mobile Node-Access Router Interface 5.1.1 MN-AR Transport Liebsch and Singh (editors) Expires December 2004 [Page 13] Internet-Draft Candidate Access Router Discovery June 2004 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, since ICMP has no provision for fragmentation above the IP level. Hosts and Access Routers use the Experimental ICMP type main header [Ke04] when CARD protocol messages cannot be conveyed via another outgoing ICMP-type message. The MN-AR interface MUST implement and SHOULD use ICMP for transport, with either the CARD ICMP header or piggybacked on another ICMP message. 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: Source Address: An IP address assigned to the sending interface. Destination Address: An IP address assigned to the receiving interface. Hop Limit: 255 ICMP Fields: Type Experimental Mobility type (To be assigned by IANA for IPv4 and IPv6, see [Ke04]). Code 0 Checksum The ICMP checksum. Subtype Experimental Mobility subtype for CARD, see [Ke04]. Liebsch and Singh (editors) Expires December 2004 [Page 14] Internet-Draft Candidate Access Router Discovery June 2004 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 the CARD Request message on the receiver side, further sub-options may be carried, serving as input to the reverse address translation function and/or capability discovery function. CARD 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 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. 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. 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. 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. Router Certificate (mandatory): The Router Certificate sub-option carries one certificate in the chain for the AR or for a Liebsch and Singh (editors) Expires December 2004 [Page 15] Internet-Draft Candidate Access Router Discovery June 2004 CAR. The chain includes certificates starting at a trusted anchor, which the router shares in common with the mobile node, to the router itself. The format of the Router Certificate Chain sub-option is described in Section 5.1.3.7. Preferences sub-option (optional): The Preferences sub-option carries information about attributes of interest to the requesting entity. Attributes are encoded according to the AVP encoding rule as 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 in case of performing optional capability pre-filtering on ARs and provides only capabilities of interest to a requesting MN. Requirements (optional): The Requirements sub-option carries information about attribute-value pairs required for pre- filtering of CARs on a MN's current AR. This parameter conveys MN specific attribute-value pairs to allow a MN's current AR to send only information about CARs of interest back to the requesting MN. CARs are filtered on ARs according to CARs' capability parameters and given policy or threshold, as encoded in the Requirements sub-option. Attribute-value pairs are encoded according to the AVP encoding rule as 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. CARD Requests which 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 for CARD_RETRY_MAX seconds occurs. 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. MNs which retransmit a CARD Request use the same CARD sequence number. This allows an AR to cache its reply to the original request and then send it again, should a duplicate request arrive. This cached information should only be held for a maximum of Liebsch and Singh (editors) Expires December 2004 [Page 16] Internet-Draft Candidate Access Router Discovery June 2004 CARD_RETRY_MAX seconds after receipt of the request. Sequence numbers SHOULD be randomly chosen to avoid duplicates if MNs restart frequently. 5.1.2 CARD Options Format All options are of the form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |Vers.| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type: 8-bit identifier of the type of option, assigned by IANA. See [Ke04] for CARD Request and CARD Reply values. Length: 8-bit unsigned integer. The length of option including the type and length fields in units of 8 octets. The value 0 is invalid. Vers.: 3-bit version code. For this specification, Vers.=1. 5.1.2.1 CARD Request Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |Vers.|P|C|A|T| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Fields: Type: To be assigned by IANA for IPv4 and IPv6, see [Ke04]. Length: The length of the option in units of 8 octets, including the type and length fields as well as sub-options. Vers.: 3-bit version code. For this specification, Vers.=1. Liebsch and Singh (editors) Expires December 2004 [Page 17] Internet-Draft Candidate Access Router Discovery June 2004 Flags: P-flag: Indicates 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.5 of this document. C-flag: Indicates that the requesting entity is interested also in associated CARs' capabilities. If the MN wants the AR to append CARs' capability parameters to the CARD Reply in addition to address information, the MN must set this flag. A-flag: Indicates that the requesting entity does NOT want the receiver of this message to perform reverse address translation. This flag is set in case CARD protocol messages are piggybacked with a protocol that performs reverse address translation. For details refer to Section 4.5 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. 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. Reserved: Initialized to zero, ignored on reception. Sequence Number: Allows correlating requests with replies. Valid Sub-Options: - L2 ID sub-option - Preferences sub-option - Requirements sub-option - Trusted Anchor sub-option To ensure meeting requirements on boundary alignment, individual sub-options MUST meet the 32-bit boundary alignment requirements respectively. To meet the 8n boundary alignment requirement of the entire CARD Request option, the CARD option reply MUST be padded if necessary to meet the 8n alignment constraint. 5.1.2.2 CARD Reply Option Liebsch and Singh (editors) Expires December 2004 [Page 18] Internet-Draft Candidate Access Router Discovery June 2004 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: To be assigned by IANA for IPv4 and IPv6 [Ke04]. Length: The length of the option in units of 8 octets, including the type and length fields as well as sub-options. Vers.: 3-bit version code. For this specification, Vers.=1. Flags: P-flag: Indicates 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.5 of this document. U-flag: Indicates an unsolicited CARD Reply. This flag is only valid on the AR-AR interface. L-flag: Set if this message is the last message in a a multiple ICMP message reply. This flag is only valid on the MN-AR interface. The flag U=1 on an AR-MN message is invalid. The flag L=1 is invalid on the MN-AR interface. The an invalid message should be discarded and an appropriate error message logged. Reserved: Initialized to zero, ignored on reception. Sequence Number: Allows correlating requests with replies. Valid Sub-Options: - L2 ID sub-option - Capability Container sub-option - Address sub-option - Router Certificate sub-option. Liebsch and Singh (editors) Expires December 2004 [Page 19] Internet-Draft Candidate Access Router Discovery June 2004 To ensure meeting requirements on boundary alignment, individual sub-options MUST meet 32-bit boundary alignment requirements respectively. To meet the 8n boundary alignment requirement of the entire CARD Reply option, the CARD option reply MUST be padded if necessary to meet the 8n alignment constraint. 5.1.3 Sub-Options Format All sub-options are of the form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len | Sub-Option Data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Option Type: 8-bit identifier of the type of option. The sub-options defined in this document are listed in the table below. The table also indicates on which interfaces the sub-option is valid. Description Type Interface | | / \ | | MN-AR AR-AR --------------------------------------------------------------- L2 ID 0x01 x Address 0x02 x Capability Container 0x03 x x Preferences 0x04 x x Requirements 0x05 x Trusted Anchor 0x06 x Router Certificate 0x07 x x Option-Length: 8-bit unsigned integer, indicating the length of the sub-option, including sub-option type and sub-option length fields. The units of length differ depending on the sub-option type. Since some sub-options have variable lengths in value, individual sub-options MUST be aligned on a 32-bit boundary. 5.1.3.1 L2 ID Sub-Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Liebsch and Singh (editors) Expires December 2004 [Page 20] Internet-Draft Candidate Access Router Discovery June 2004 |Sub-Option Type|Sub-Option Len | Context-ID | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2-Type | L2 ID . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Sub-Option Type: 0x01 Sub-Option Length: Length of the sub-option (including type and length fields) in units of octets. Context-ID: Associated L2 ID, IP address and capability parameters that belong to the same AR IP address but are encoded in separate sub-options. 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. The following status codes are specified: 0x00: NONE - This value MUST be set when the L2 ID is included in a CARD Request. 0x01: CANDIDATE - This value MUST to be set by an AR when sending a L2 ID sub-option in a CARD Reply for information about candidate APs' L2 IDs. Candidate L2 IDs are sent if a MN did not request resolution of specific L2 IDs with a CARD Request. If CANDIDATE is set, the AR MUST set the Context-ID field of individual parameters to a value that allows matching associated L2 ID, address and capability information on the receiver side. 0x02: MATCH - This value is set by an AR 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 suboption to the Context-ID for one of the previously resolved L2 IDs. 0x03: RESOLVER ERROR - This value MUST be set by an AR in case the L2 ID cannot be resolved. The AR sets this value for the Status Code in the returned L2 ID sub-option. Liebsch and Singh (editors) Expires December 2004 [Page 21] Internet-Draft Candidate Access Router Discovery June 2004 L2 type: Indicates the interface type Allocated by 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. 5.1.3.2 Preferences Sub-Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len | Preferences +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Option Type: 0x04 Sub-Option Length: Length of the sub-option (including type and length fields) in units of octets. Preferences: List of capability attribute values (Section 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, since the preferences are indicated only with a list of 16-bit encoded ATTRIBUTE fields. In case 32-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. The use of the Preferences sub-option is optional and for optimization purpose. 5.1.3.3 Requirements Sub-Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len | Requirements +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Option Type: 0x05 Sub-Option Length: Length of the sub-option (including type and length Liebsch and Singh (editors) Expires December 2004 [Page 22] Internet-Draft Candidate Access Router Discovery June 2004 fields) in units of octets. Requirements: AVP encoded requirements (see Section 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) field MUST be present and set appropriately. The use of the Requirements sub-option is optional and for optimization purpose. 5.1.3.4 Capability Container Sub-Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len | Context-ID |P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Sub-Option Type: 0x03 Sub-Option Length: Length of the sub-option (including type and length fields)in units of 8 octets. Context-ID: L2 ID, IP address and capability parameters that belong to the same node (AR) but are encoded in separate sub-options. Flags: P-flag: Indicates piggybacking capability of the CAR whose capabilities are conveyed in this Capability Container. This flag allows a MN already after a CARD process to know about a selected new AR's piggybacking capability. Reserved: Initialized to zero, ignored on reception. AVPs: AVPs are a method of encapsulating capability information relevant for the CARD protocol. See Section 5.1.4 for the AVP encoding rule. 5.1.3.5 Address Sub-Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Liebsch and Singh (editors) Expires December 2004 [Page 23] Internet-Draft Candidate Access Router Discovery June 2004 |Sub-Option Type|Sub-Option Len | Context-ID | Address Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - Sub-Option Type: 0x02 Sub-Option Length: Length of the sub-option (including type and length fields) in units of octets. Context-ID: Indicates the L2 ID, IP address and capability parameters that belong to the same AR IP address but are encoded in separate sub-options. Address Type: Indicates the type of the address. 0x01 IPv4 0x02 IPv6 Address: The Candidate Access Router's IP address. 5.1.3.6 Trusted Anchor Sub-Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type|Sub-Option Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Trusted Anchor Name +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - Sub-Option Type: 0x06 Sub-Option Length: Length of the sub-option (including type and length fields) in units of 8 octets. Reserved: Initialized to zero, ignored on reception. Trusted Anchor Name: DER encoding for X.501 name of trusted anchor. 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. 5.1.3.7 Router Certificate Sub-Option Liebsch and Singh (editors) Expires December 2004 [Page 24] Internet-Draft Candidate Access Router Discovery June 2004 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Certificate +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - Sub-Option Type: 0x07 Sub-Option Length: Length of the sub-option (including type and length fields) in units of 8 octets. Reserved: Initialized to zero, ignored on reception. Certificate: X.509v3 router certificate (see [Arkko04] for more detail on certificate profile) 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 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 in the L2-ID and Address sub- options. 5.1.4 Capability AVP encoding rule 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. Liebsch and Singh (editors) Expires December 2004 [Page 25] Internet-Draft Candidate Access Router Discovery June 2004 AVP Length: The two octet AVP length field indicates the number of octets in this AVP, including the AVP Code, AVP Length, Reserved, Lifetime and Data field. Reserved: Initialized to zero, ignored on reception. Lifetime: Specifies the lifetime of the encoded capability in seconds. In 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. Data: This variable length field has the Value of the capability attribute encoded. Note: This document provides no detailed information on how to encode the capability attribute's value, which is to be encoded in the Data field. Details on the interpretation of individual capability parameters are out of scope of this document. 5.2 CARD Inter-Access Router Messages 5.2.1 AR-AR Transport Since the types of access networks in which CARD might be useful are not today 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 prototype deployments of CARD SHOULD use Stream Control Transport Protocol (SCTP) [Stew00] for 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 such SCTP features for CARD is not recommended at this time. The SCTP Payload Data Chunk carries the CARD messages. CARD messages on the inter-router interface consist of just the CARD Request or Liebsch and Singh (editors) Expires December 2004 [Page 26] Internet-Draft Candidate Access Router Discovery June 2004 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. 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 is unlikely to be more than one CARD transaction between two routers active at any one time, having ordered delivery simplifies the implementation. The Payload Protocol Identifier in the SCTP header is 'CARD'. CARD uses the Seamoby SCTP port number [Ke04]. The format of Payload Data Chunk taken from [Stew00] is shown in the following diagram. 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]. 'E' bit The Ending fragment bit. See [Stew00]. TSN Transmission Sequence Number. See [Stew00]. Stream Identifier S Identifies the CARD stream. Stream Sequence Number n Sequence number. See [Stew00]. Liebsch and Singh (editors) Expires December 2004 [Page 27] Internet-Draft Candidate Access Router Discovery June 2004 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 an AR that is not in its CARD 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 sent unsolicited CARD Replies to all its CARs to make sure their CARD tables are properly populated. 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. If a CARD deployment will never run over the public Internet, and 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, including using retransmits with exponential backoff, etc. In addition, it is an open research question whether SCTP is an appropriate transport protocol for all inter-router CARD operations. 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. 5.2.2 Protocol Payload Types The AR-AR interface uses the CARD Request option and CARD Reply option directly in the body of the SCTP User Data field. The sequence number for the CARD Request on the AR-AR interface is initialized to zero when the AR reboots, and incremented every time a CARD Request message is sent. The replying AR includes sequence number from the CARD Request in the CARD Reply. If an unsolicited CARD Reply is sent, the sending AR increments the sequence number. 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 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 Liebsch and Singh (editors) Expires December 2004 [Page 28] Internet-Draft Candidate Access Router Discovery June 2004 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. 6. SECURITY CONSIDERATIONS 6.1 Veracity of CARD Information The veracity of the CARD protocol depends on the ability of an AR to obtain accurate information about geographically neighboring ARs, and to provide such 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 itself 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 draft 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. 6.2 Security Association between AR and AR CARD does contain 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. 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. 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. 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. Liebsch and Singh (editors) Expires December 2004 [Page 29] Internet-Draft Candidate Access Router Discovery June 2004 If CARD is used to exchange information between different administrative domains, additional security policy issues may apply. Such issues are out of 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. 6.3 Security Association between AR and MN 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. 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 [SEND]. Since CARD is a discovery protocol, confidentiality is not necessary in general on the MN-AR interface. In specific cases where different network operators are sharing 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. 6.4 Router Certificate Exchange Because SEND is only available in IPv6, the procedures for obtaining certificates differ depend on whether CARD is used with IPv4 or IPv6. In IPv6, when the MN receives a CARD reply with signature from a router 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 certificate chain for this purpose, and MNs MUST be configured with a set of certificates for shared trusted anchors to allow verification of the AR certificates. A MN may not necessarily need to use Cryptographically Generated Addresses (CGAs) Liebsch and Singh (editors) Expires December 2004 [Page 30] Internet-Draft Candidate Access Router Discovery June 2004 with CARD, CGA support is OPTIONAL for CARD. A certificate profile for ARs is described in the SEND specification [Arkko04]. In IPv4, there is no DCS/DCA message for obtaining the certificate. In that case, if the MN does not have a certificate for the router, 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 certificate, to obtain the certificate chain for the current AR. 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 certificate chain, matching one of the requested trust anchors, and no other sub-options, setting the Context-ID of all sub-options to match. If the chain is longer than one certificate, the router sends the LD 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. 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 the certificates are still valid. Certificate chains 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 option for the AP for which the CAR certificate is desired, and the AR replies as above, except 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. Because the amount of space in an ICMP message is limited, the router certificate chains SHOULD be kept short. 6.5 DoS Attack 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. A suggested rate limiting policy is the following. If the number of CARD messages exceeds CARD_REQUEST_RATE, the AR SHOULD begin to randomly drop messages 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 assures that messages Liebsch and Singh (editors) Expires December 2004 [Page 31] Internet-Draft Candidate Access Router Discovery June 2004 from unknown entities will be discarded immediately during IPsec processing. MNs MUST discard CARD Replies for which there is no outstanding CARD Request, indicated by the sequence number. 6.6 Replay Attacks To protect against replay attacks on the AR-AR interface, ARs SHOULD enable replay protection when negotiating the IPsec security association using IKE. 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 since the MN in any case ignores the reply. 7. PROTOCOL CONSTANTS Constant Section Default Value Meaning -------------------------------------------------------------------- CARD_REQUEST_RETRY 4.4 2 seconds Wait interval before initial retransmit on MN-AR interface. CARD_RETRY_MAX 4.4 15 seconds Give up on retry on MN-AR interface. CARD_STARTUP_WAIT 5.2.1 1-3 seconds Maximum startup wait for an AR before performing AR-AR CARD. CARD_MIN_UPDATE_INTERVAL 5.2.1 60 seconds Minimum AR-AR update interval. CARD_REQUEST_RATE 6.5 2 requests/ Maximum number of sec. messages before AR institutes rate limiting. 8. IANA CONSIDERATIONS See [Ke04] for instructions on IANA allocation. 9. NORMATIVE REFERENCES [Brad97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Liebsch and Singh (editors) Expires December 2004 [Page 32] Internet-Draft Candidate Access Router Discovery June 2004 [Kemp02] Kempf, J., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, September 2002. [NaNS98] Narten, T., et al., "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [Post80] Postel, J., "User Datagram Protocol", RFC 768, August 1980. [Stew00] Stewert, R., et. al., "Stream Control Transmission Protocol", RFC 2960, October, 2000. [AtKe98] Atkinson, R., Kent, S.,"IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [NaAl98] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. [HarCar98] Harkins, D., and Carrel, D., "The Internet Key Exchange", RFC 2409, November, 1998. [Arkko04] Arkko, J., editor, Kempf, J., Sommerfelt, B., Zill, B., and Nikander, P., "SEcure Neighbor Discovery(SEND)", Internet draft, Work in progress. [Ke04] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", Internet Draft, Work in progress. 10. INFORMATIVE REFERENCES [TKCK02] Trossen, D., Krishanmurthi, G. Chaskar, H., Kempf, J., "Issues in candidate access router discovery for seamless IP-level handoffs", Internet Draft, Work in progress. [Kris02] Krishanmurti, G., "Requirements for CAR Discovery Protocols", Internet Draft, Work in progress. [Kenw02] Kenward, B., "General Requirements for Context Transfer", Internet Draft, Work in progress. [MaKo03] Manner, J., Kojo, M. (Ed), "Mobility Related Terminology", Internet Draft, Work in progress. [Kood03] Koodli, R, et al., "Fast handoffs for Mobile IPv6", Internet Draft, Work in progress. [Funa02] Funato, D. et al., "Geographically Adjacent Access Router Discovery Protocol", Internet Draft, Work in progress. Liebsch and Singh (editors) Expires December 2004 [Page 33] Internet-Draft Candidate Access Router Discovery June 2004 [Tros03] Trossen, D. et al., "A Dynamic Protocol for Candidate Access-Router Discovery", Internet Draft, Work in progress. [ShGi00] Shim, E., Gitlin, R., "Fast Handoff Using Neighbor Information", Internet Draft, Work in progress. [Malk03] El Malki, K. et al., "Low Latency Handoffs in Mobile IPv4", Internet Draft, Work in progress. 11. AUTHORS' ADDRESSES Hemant Chaskar Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA Phone: +1 781-993-3785 Email: Hemant.Chaskar@nokia.com Daichi Funato NTT DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110, USA Phone: +1 408-451-4736 Email: funato@docomolabs-usa.com Marco Liebsch NEC Network Laboratories Kurfuersten-Anlage 36 , 69115 Heidelberg Germany Phone: +49 6221-90511-46 Email: marco.liebsch@ccrle.nec.de Eunsoo Shim NEC Laboratories America, Inc. 4 Independence Way Princeton, NJ 08540, USA Phone: +1 609-951-2909 Email: eunsoo@nec-labs.com Ajoy Singh Motorola Inc 1501 West Shure Dr, USA Phone: +1 847-632-6941 Email: asingh1@email.mot.com 12. IPR STATEMENTS The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this Liebsch and Singh (editors) Expires December 2004 [Page 34] Internet-Draft Candidate Access Router Discovery June 2004 document. For more information consult the online list of claimed rights. Please refer to http://www.ietf.org/ietf/IPR for more information. 13. COPYRIGHT NOTICE "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." 14. CONTRIBUTORS The authors would like to thank Vijay Devarapalli (Nokia) and Henrik Petander (Helsinki University of Technology) for formally reviewing the protocol specification draft and providing valuable comments and input for technical discussions. The authors would also like to thank James Kempf for reviewing and providing lots of valuable comments and editing help. 15. ACKNOWLEDGEMENTS The authors would like to thank (in alphabetical order) Dirk Trossen, Govind Krishnamurthi, James Kempf, Madjid Nakhjiri, Pete Liebsch and Singh (editors) Expires December 2004 [Page 35] Internet-Draft Candidate Access Router Discovery June 2004 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. Liebsch and Singh (editors) Expires December 2004 [Page 36] Internet-Draft Candidate Access Router Discovery June 2004 APPENDIX A: MAINTENANCE OF ADDRESS MAPPING TABLES IN ACCESS ROUTERS 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 and intention of this appendix is to provide only a basic idea on flexibly extensions to the CARD protocol as described in this document. Appendix A.1 Centralized Approach using a Server Functional Entity 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 neighboring AR(s) to 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. 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 a MN discovers the L2 ID of APs during L2 scanning, the MN passes one or more L2 ID(s) to its current AR and the AR resolves it 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 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. An initial idea of performing reverse address translation using a centralized server has been described in [Funa02]. Liebsch and Singh (editors) Expires December 2004 [Page 37] Internet-Draft Candidate Access Router Discovery June 2004 +----------+ +------------>| 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 Appendix A.2 Decentralized Approach using Mobile Terminals' Handover 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. 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 not refreshed before the timeout period expires and are created or refreshed according to the following mechanism. 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 Liebsch and Singh (editors) Expires December 2004 [Page 38] Internet-Draft Candidate Access Router Discovery June 2004 bootstrap handover to invoke the discovery procedure and the subsequent handover serves to refresh the association between the neighboring ARs. After the bootstrap handover, the MNs can perform CARD and thus seamless handover using the CAR information. This idea was presented in [ShGi00] and [Tros03]. Maintenance of the CAR table is done using an additional option for the CARD protocol operation performed between a MN and its current AR. This message serves as Router Identity message. 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. 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. 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 it to a later time when some MN undergoing handover between them performs CARD as described in Section 4. In the later (refresh) case, ARs may exchange capabilities or defer it until a later time when another MN undergoes handover. Finally, note that in a handover-based protocol, a first handover between a pAR and a MN's current AR cannot use CARD, as this handover bootstraps the CAR table. However, in long term, such a handover will only amount to a small fraction of total successful handover between the two AR(s). Also, if the MN engaging in such a Liebsch and Singh (editors) Expires December 2004 [Page 39] Internet-Draft Candidate Access Router Discovery June 2004 first handover is running a non-delay sensitive application at the time of handover, the user may not even realize its impact. Liebsch and Singh (editors) Expires December 2004 [Page 40] Internet-Draft Candidate Access Router Discovery June 2004 APPENDIX B: APPLICATION SCENARIOS This section provides two examples of an application scenario 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. Appendix B.1 CARD Operation in a Mobile IPv6 Enabled Wireless LAN Network 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. ----------------------------- / \ +----+ | NETWORK |---| HA | \ / +----+ ----------------------------- | | +-----+ +-----+ | AR1 |---------+ | AR2 | +-----+ | +-----+ | subnet 1 | |subnet 2 +-----+ +-----+ +-----+ | AP1 | | AP2 | | AP3 | +-----+ +-----+ +-----+ ^ ^ ^ \ \ \ v +-----+ | MN | - - ->>>- - - ->>> +-----+ Figure B.1: Assumed network topology A Mobile IPv6 Home Agent (HA), maintains location information for the MN in its binding cache. From 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 Liebsch and Singh (editors) Expires December 2004 [Page 41] Internet-Draft Candidate Access Router Discovery June 2004 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 or not approaching APs are eligible candidates for a handover. Assume 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 it to its current 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. Respective IP address of the candidate AR, to which AP3 is connected to, is the address of AR2. Since IP addresses of the MN's CARs are now known to AR1, AR1 retrieves the CARs' capabilities from the CAR table, assumed it has valid entries for respective capability parameters To refresh dynamic capabilities, whose associated lifetime in AR1's CAR table has 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. AR2 in response sends a CARD Reply message back to AR1, encapsulating the requested capability parameters with the signaling message, in a Capability Container sub-option. Now, 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. On reception of the CARD Reply message, the MN performs target AR selection, taking AR1's and AR2's capability parameters as well as associated APs' link-quality parameters into account. In case the selected AP is AP2, no IP handover needs to be performed. In case AP3 and the associated AR2 are selected, the MN needs to perform an IP handover according to the Mobile IPv6 protocol operation. Figure B.2 illustrates the signaling flow of the previously described application scenario of CARD within a Mobile IPv6 enabled network. MN AP1 AR1 AP2 AP3 AR2 | | | | | | | connected | | | | | 0-------------0-------0 | | | Liebsch and Singh (editors) Expires December 2004 [Page 42] Internet-Draft Candidate Access Router Discovery June 2004 | | | | | | | | | | | | | | | | | <~~~~~~~~~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. Appendix B.2 CARD Operation in a Fast Mobile IPv6 Network This application scenario assumes ARs can perform the fast handover protocol sequence for Mobile IPv6 [Kood03]. The MN scans for new APs Liebsch and Singh (editors) Expires December 2004 [Page 43] Internet-Draft Candidate Access Router Discovery June 2004 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). 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 (potentially replaces the "New Attachment Point Link-Layer Address" option of the Fast Mobile IPv6 protocol). The pAR resolves the received list of candidate APs' L2 IDs to the IP address 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 reception of the CARs' capability information, the pAR updates its local CAR table and forwards the address and capability information to the MN of 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. 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. Figure B.3 illustrates how CARD protocol messages and functions work together with the Fast Mobile IPv6 protocol. 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*-| | Liebsch and Singh (editors) Expires December 2004 [Page 44] Internet-Draft Candidate Access Router Discovery June 2004 |<------PrRtAdv-------| | | | [MN-AR CARD Repl] | | | | | | | NAR selection | | | |------F-BU---------->|--------HI--------->| | | |<------HACK---------| | | <--F-BACK--|--F-BACK--> | | | | | | Disconnect | | | | forward | | | packets===============>| | | | | | | | | | Connect | | | | | | | RS (with FNA option)======================>| | |<-----------RA (with NAACK option)--------| | |<=================================== deliver packets | | | | Figure B.3: Fast Handover protocol sequence with CARD protocol options *) In Figure B.3, the CARD protocol interaction between the pAR and CARs is only required in case 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' address and capability information from its CAR table. Liebsch and Singh (editors) Expires December 2004 [Page 45]