idnits 2.17.1 draft-ietf-seamoby-card-protocol-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1781. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1758. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1765. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1771. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 10 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2004) is 7162 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'SEND' is mentioned on line 1522, but not defined == Unused Reference: 'Kemp02' is defined on line 1650, but no explicit reference was found in the text == Unused Reference: 'NaNS98' is defined on line 1654, but no explicit reference was found in the text == Unused Reference: 'Post80' is defined on line 1657, but no explicit reference was found in the text == Unused Reference: 'NaAl98' is defined on line 1665, but no explicit reference was found in the text == Unused Reference: 'Kris02' is defined on line 1684, but no explicit reference was found in the text == Unused Reference: 'Kenw02' is defined on line 1687, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. 'NaNS98') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2960 (ref. 'Stew00') (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 2406 (ref. 'AtKe98') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2434 (ref. 'NaAl98') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2409 (ref. 'HarCar98') (Obsoleted by RFC 4306) Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Seamoby Working Group 2 Internet Draft Marco Liebsch 3 Category: Experimental Ajoy Singh 4 (Editors) 5 Hemant Chaskar 6 Daichi Funato 7 Eunsoo Shim 8 draft-ietf-seamoby-card-protocol-08.txt 9 Expires: March 2005 September 2004 11 Candidate Access Router Discovery 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance 18 with RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 To enable seamless IP-layer handover of a mobile node (MN) from one 38 access router (AR) to another, the MN is required to discover the 39 identities of candidate ARs (CARs) for handover, along with their 40 capabilities, prior to the initiation of the IP-layer handover. The 41 act of discovery of CARs has two aspects to it: identifying the IP 42 addresses of the CARs and finding the capabilities of those CARs. 43 This process is called "candidate access router discovery" (CARD). At 44 the time of IP-layer handover, that CAR, whose capabilities is a good 45 match to the preferences of the MN, is chosen as the target AR for 46 handover. The protocol described in this document allows a mobile 47 node to perform CARD. 49 TABLE OF CONTENTS 51 1. INTRODUCTION...................................................3 52 2. TERMINOLOGY....................................................3 53 3. CARD PROTOCOL FUNCTIONS........................................4 54 3.1 Reverse Address Translation................................4 55 3.2 Discovery of CAR Capabilities..............................4 56 4. CARD PROTOCOL OPERATION........................................5 57 4.1 Conceptual Data Structures.................................8 58 4.2 Mobile Node - Access Router Operation......................8 59 4.3 Current Access Router - Candidate Access Router Operation.11 60 4.4 CARD Protocol Message Piggybacking on the MN-AR Interface.13 61 5. PROTOCOL MESSAGES.............................................14 62 5.1 CARD Messages for the Mobile Node-Access Router Interface.14 63 5.2 CARD Inter-Access Router Messages.........................28 64 6. SECURITY CONSIDERATIONS.......................................30 65 6.1 Veracity of CARD Information..............................30 66 6.2 Security Association between AR and AR....................31 67 6.3 Security Association between AR and MN....................31 68 6.4 Router Certificate Exchange...............................32 69 6.5 DoS Attack................................................33 70 6.6 Replay Attacks............................................33 71 7. PROTOCOL CONSTANTS............................................34 72 8. IANA CONSIDERATIONS...........................................34 73 9. NORMATIVE REFERENCES..........................................34 74 10. INFORMATIVE REFERENCES.......................................35 75 11. AUTHORS' ADDRESSES...........................................36 76 12. IPR STATEMENTS...............................................36 77 13. DISCLAIMER OF VALIDITY.......................................37 78 14. COPYRIGHT NOTICE.............................................37 79 15. ACKNOWLEDGEMENTS.............................................37 81 Appendix A MAINTENANCE OF ADDRESS MAPPING TABLES IN 82 ACCESS ROUTERS. . . . . . . . . . . . . . . . . . . 39 83 Appendix A.1 Centralized Approach using a Server Functional 84 Entity. . . . . . . . . . . . . . . . . . . . . . . 39 85 Appendix A.2 Decentralized Approach using Mobile Terminals' 86 Handover. . . . . . . . . . . . . . . . . . . . . . 40 88 Appendix B APPLICATION SCENARIOS . . . . . . . . . . . . . . . 43 89 Appendix B.1 CARD Operation in a Mobile IPv6 Enabled Wireless 90 LAN Network . . . . . . . . . . . . . . . . . . . . 43 91 Appendix B.2 CARD Operation in a Fast Mobile IPv6 enabled 92 network . . . . . . . . . . . . . . . . . . . . . . 46 94 Conventions used in this document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC-2119 [Brad97]. 100 1. INTRODUCTION 102 IP mobility protocols, such as Mobile IP, enable mobile nodes to 103 execute IP-level handover among access routers. Additionally, work 104 is underway [Kood03][Malk03] to extend the mobility protocols to 105 allow seamless IP handover. The pre-requisite for the seamless IP 106 mobility protocols is the knowledge of candidate access routers 107 (CARs) to which a mobile node can be transferred. The CAR discovery 108 protocol enables the acquisition of information about the access 109 routers that are candidates for the mobile node's next handover. 111 CAR discovery involves identifying a CAR's IP address as well as the 112 capabilities that the mobile node might use for a handover decision. 113 There are cases when a mobile node has a choice of CARs. The mobile 114 node chooses one based on a match between the mobile node's 115 requirements for a handover candidate and the CAR's capabilities. 116 However, the decision algorithm itself is out of scope of this 117 document. 119 The problem statement for CAR discovery is documented in [TKCK02]. 120 In this document, a protocol is described to perform CAR discovery. 121 Section 3 describes two main functions of the CAR discovery 122 protocol. Section 4 describes the core part of the CARD protocol 123 operation. The protocol message format is described in Section 5. 124 Section 6 discusses security considerations and Section 7 contains a 125 table of protocol parameters. Appendix A contains two alternative 126 techniques for dynamically constructing the CAR table mapping 127 between the access point L2 ID and Access Router IP address, 128 necessary for reverse address translation. The default method is 129 static configuration. Appendix B contains two sample scenarios for 130 using CARD. 132 2. TERMINOLOGY 134 This document uses terminology defined in [MaKo03]. 136 In addition, the following terms are used: 138 Access Router (AR) 140 An IP router residing in an access network and connected to one or 141 more APs. An AR offers IP connectivity to MNs. 143 Candidate AR (CAR) 145 An AR to which a MN has a choice when performing IP-level handover. 147 Capability of an AR 149 A characteristic of the service offered by an AR that may be of 150 interest to a MN when the AR is being considered as a handover 151 candidate. 153 L2 ID 155 Identifier of an AP that uniquely identifies that AP. For example, in 156 802.11, this could be a MAC address of an AP. 158 CARD Initiating Trigger 160 L2 trigger used to initiate the CARD process. For example, a MN can 161 initiate CARD as soon as it detects the L2 ID of a new AP during link 162 layer scan. 164 Access Point (AP) 166 A wireless access point, identified by a MAC address, providing 167 service to the wired network for wireless nodes. 169 3. CARD PROTOCOL FUNCTIONS 171 The CARD protocol accomplishes the following functions. 173 3.1 Reverse Address Translation 175 If a MN can listen to the L2 IDs of new APs prior to making a 176 decision about IP-level handover to CARs, a mechanism is needed for 177 reverse address translation. This function of the CARD protocol 178 enables the MN to map the received L2 ID of an AP to the IP address 179 of the associated CAR that connects to the AP. To get the CAR's IP 180 address, the MN sends the L2 ID of the AP to the current AR and the 181 current AR provides the associated CAR's IP address to the MN. 183 3.2 Discovery of CAR Capabilities 185 Information about capabilities of CARs can assist the MN in making 186 optimal handover decisions. This capability information serves as 187 input to the target AR selection algorithm. Some of the capability 188 parameters of CARs can be static, while others can change with time. 190 Definition of capabilities is out of scope of this document. Encoding 191 rules for capabilities and the format of a capability container for 192 capability transport are specified in Section 5. 194 4. CARD PROTOCOL OPERATION 196 The CARD protocol allows MNs to resolve the L2 ID of one or more APs 197 to the IP address of the associated CARs. The L2 IDs are typically 198 discovered during operation by the MN and are potential handover 199 candidates. Additionally, CARD allows MNs to discover particular 200 capabilities associated with the CARs, such as available bandwidth, 201 that might influence the handover decision of the MN. Furthermore, 202 the protocol allows ARs to populate and maintain their local CAR 203 table (Section 4.1) with the capabilities of CARs. For this, the 204 CARD protocol makes use of CARD Request and CARD Reply messages 205 between a MN and its current AR (Section 5.1.2), and between a MN's 206 current AR and individual CARs respectively (Section 5.2.2). 208 To allow a MN to retrieve a CARs' address and capability 209 information, the CARD Request and CARD Reply messages used between a 210 MN and its current AR may contain one or more access points' L2 IDs 211 and the IP addresses of associated CARs respectively. Optionally, 212 the CARD Reply messages can also contain CARs' capability 213 information. A CAR's capabilities are specified as a list of 214 attribute-value pairs, which are conveyed in a Capability Container 215 message parameter. 217 Information about the CAR(s) and associated capabilities MAY be used 218 by the MN to perform target access router selection during its IP 219 handover. The current AR returns replies based on its CAR table (see 220 Section 4.1), and returns a RESOLVER ERROR (see Section 5.1.3.1) if 221 the request cannot be resolved. 223 The CARD protocol also enables a MN to optionally indicate its 224 preferences on capabilities of interest to its current AR by 225 including the Preferences message parameter in the CARD Request 226 message. The MN's current AR MAY use this information to perform 227 optional capability pre-filtering for optimization purposes and 228 returns only these capabilities of interest to the requesting MN. 229 The format of this optional Preferences message parameter is 230 described in Section 5.1.3.2. 232 Optionally, the MN can provide its current AR with a list of 233 capability attribute-value pairs, indicating not only the capability 234 parameters (attributes) as required for capability pre-filtering, 235 but also a specific value for a particular capability. This allows 236 the MN's current AR performing CAR pre-filtering and to send only 237 address and capability information of CARs, whose capability values 238 meet the requirements of the MN, back to the requesting MN. The 239 format of this optional Requirements message parameter is described 240 in Section 5.1.3.3. 242 As an example, using the optional Preferences message parameter, a 243 MN may indicate to its current AR that it is interested only in 244 IEEE802.11a interface specific capability parameters, since this is 245 the only interface the MN has implemented. Hence, the MN's current 246 AR sends back only CARs' IEEE802.11a specific capabilities. 247 Similarly, using the optional Requirements message parameter, a MN 248 may indicate to its current AR that it is only interested in CARs 249 that can satisfy a given QoS constraint. Here, a MN sends the 250 respective QoS attribute with the QoS constraint value to its 251 current AR using the optional Requirements message parameter. The 252 QoS constraint is denoted as an attribute-value pair and 253 encapsulated with the Requirements message parameter, which is 254 appended to the MN-originated CARD Request message. The Requirements 255 message parameter may be used to indicate the cut off values of the 256 capabilities for the desired CAR(s). Based on the received optional 257 list of attributes in the Preferences parameter or a list of 258 attribute-value pairs in the Requirements message parameter, the 259 MN's current AR MAY use these parameters for deciding the content of 260 the solicited CARD Reply message, which is to be sent back to the 261 MN. Alternatively, in case no optimization with regard to capability 262 or CAR pre-filtering is performed by the MN's current AR, the 263 current AR MAY choose to silently ignore the optional Requirements 264 and Preferences message parameter as received in the CARD Request 265 message. 267 The MN can additionally request from the AR a certification path 268 that is anchored at a certificate from a shared, trusted anchor. The 269 MN includes in the CARD Request message a list of trusted anchors 270 for which the MN has a certificate and the AR replies with the 271 certification path. If no match is found, the AR returns the trusted 272 anchor names from the CARD Request. The MN can ask for a chain for 273 either the current AR or for a CAR. If the trusted anchor list is 274 accompanied by an AP L2 ID for the MN's current AP, the returned 275 chain is for the current AR. If the L2 ID is for an AP that the MN 276 has heard during scanning and is not connected to the current AR, 277 the returned chain is for a CAR. The chain is returned as a sequence 278 of CARD Reply messages, each message containing a single 279 certificate, the L2 identifier for the AP sent in the CARD Request 280 and a router address for the CAR (or for the AR itself if a request 281 was made for the AR). When the chain is complete, the MN can use it 282 to obtain the router's certified key, and thereby validate 283 signatures on CARD messages, and other messages between the MN and 284 AR. The MN only needs to send the trusted anchor option if it does 285 not have the certification path for the router already cached. If the 286 mobile node has the certification path cached, either through 287 preconfiguration, previous receipt of the chain from this router, or 288 through having received the chain through a previous router, then the 289 trusted anchor does not need to be sent. More information about 290 certificate exchange and its use in CARD security can be found in 291 Section 6. 293 The CARD protocol operation, as described in this section, 294 distinguishes signaling messages exchanged between a MN and its 295 current AR and signaling messages exchanged between ARs. Hence, 296 description of signaling messages described in the following 297 sections has a preceding identifier, referring to the associated 298 interface. Messages that are exchanged between a MN and AR are 299 designated as "MN-AR", messages between ARs are designated as "AR- 300 AR" respectively. 302 +--------------+ (1a)AR-AR CARD Request +----------+ 303 | Current |------------------------->| CAR | 304 | AR |<-------------------------| | 305 +--------------+ (2a)AR-AR CARD Reply +----------+ 306 ^ | 307 | | MN-AR 308 MN-AR | | CARD Reply(3m) 309 CARD Request(2m) V 310 +--------------+ 311 | Mobile | 312 | Node |<-- CARD Init Trigger 313 +--------------+ (1m) 315 Figure 1: MN initiated CARD Protocol Overview 317 Figure 1 describes the operation of the MN-AR CARD Request/Reply 318 protocol and AR-AR CARD Request/Reply protocol. On reception of the 319 access points' L2 IDs or the appearance of a CARD initiation trigger 320 (1m), the MN may pass on one or more AP L2 ID(s) to its current AR 321 using the MN-AR CARD Request message (2m). In case the MN wants its 322 AR to perform capability discovery in addition to reverse address 323 translation, this must be indicated in the MN-AR CARD Request 324 message by setting the C-flag. If the C-flag is not set, the AR 325 receiving the CARD Request message will perform only reverse address 326 translation. The MN's current AR resolves the L2 ID to the IP 327 address of the associated CAR or, in case the MN has not attached 328 any L2 ID message parameters, it just reads out all CARs' IP address 329 information using the reverse address translation information (L2 ID 330 to IP address mapping) from its local CAR table. The current AR then 331 returns to the MN using the MN-AR CARD Reply message (3m) the IP 332 address of the CAR(s), each CAR's set of L2 IDs with CANDIDATE 333 indicated in the L2 ID sub-option status field, and, in case 334 capability information has been requested, associated capabilities. 336 For the AR-AR CARD Request/Reply protocol, the requesting AR sends a 337 CARD Request message to its peer when the CAR table entries time out 338 (1a). The peer returns a CARD Reply message with the requested 339 information (2a). 341 4.1 Conceptual Data Structures 343 AR(s) SHALL maintain a L2-L3 address mapping table (CAR table) that 344 is used to resolve L2 IDs of candidate APs to the IP address of the 345 associated CAR. By default, this address-mapping table is configured 346 statically for the CARD protocol operation. Optionally, the CAR 347 table MAY be populated dynamically. Two possible approaches are 348 described in Appendices A.1 and A.2 respectively. 350 ARs SHOULD also keep and maintain individual CARs' capabilities in 351 the local CAR table, taking the associated capability lifetime into 352 account. If the lifetime of an individual capability entry has 353 expired, the respective capability information is updated. 354 An AR may also initiate capability exchange prior to expiration of 355 the capabilities associated with a CAR in the CAR table thereby 356 populating its CAR table. The ARs' CAR table may be implemented 357 differently, hence additional details are not provided here. ARs 358 MUST maintain their own AP to AR mappings and capability information 359 in their CAR tables, in order to provide newly booted MNs with this 360 information and so that a MN can obtain the AR's certification path. 362 MNs SHOULD maintain discovered address and capability information of 363 CARs in a local cache to avoid requesting the same information 364 repeatedly and to select an appropriate target AR from the list of 365 CARs as quickly as possible when a handover is imminent. 367 4.2 Mobile Node - Access Router Operation 369 4.2.1 Mobile Node Operation 371 To initiate CARD, a MN sends a CARD Request to its current AR, 372 requesting it to resolve the L2 ID of nearby access points to the IP 373 address of associated CARs, and also to obtain capability parameters 374 associated with these CARs. In case the requesting MN wants its 375 current AR to resolve specific L2 IDs, the MN-AR CARD Request MUST 376 contain the CARD protocol specific L2 ID message parameters. If the 377 MN wants its AR to perform only reverse address translation without 378 appending the CARs' capabilities, the MN refrains from setting the 379 C-flag in the CARD Request message. If the MN wants to perform 380 capability discovery, the CARD Request MUST have set the C-flag. The 381 CARD Request MAY also contain the Preferences or Requirements 382 message parameter, indicating the MN's preferences on capability 383 attributes of interest or its requirements on CARs' capability 384 attribute-value pairs. 386 In case the MN appends multiple L2 ID sub-options to a CARD Request, 387 the AR MUST assume each L2 ID is associated with an AP that connects 388 to a different CAR. Since L2 IDs, address information and capability 389 information are transmitted with separate sub-options, each sub- 390 option carries a Context-ID, to allow matching parameters that 391 belong together. Hence, the MN MUST assign different Context-ID 392 values to the L2 ID sub-options it appends to the CARD Request 393 message. The Status-Code field of the L2 ID sub-option MUST always 394 be set to NONE (0x00) by a MN. The MN MUST set the sequence number 395 to a randomly generated value, and the AR MUST include the sequence 396 number in all messages of the reply. If the reply spans multiple 397 messages, each message contains the same sequence number. 399 Upon receipt of the corresponding MN-AR CARD Reply message, the MN 400 correlates the CARD Reply with the appropriate CARD Request message 401 and then processes all MN-AR CARD Reply message parameters to 402 retrieve its CARs' address and capability information. If the MN is 403 unable to correlate the CARD Reply with any previously sent CARD 404 Request messages, the MN SHOULD silently discard the reply. This may 405 happen when the MN reboots after sending a CARD Request Message to 406 the connected AR. 408 A MN uses exponential backoff to retransmit the CARD Request in the 409 event a CARD Reply is not received within CARD_REQUEST_RETRY 410 seconds. The retransmitted CARD Request MUST have the same sequence 411 number as the original. With the exception of certification paths, 412 which are large by nature, an AR SHOULD attempt to limit the 413 information in a CARD Reply to a single message. Should that not be 414 possible, the AR MAY send the reply in multiple messages. The last 415 message of a reply MUST always have the L-flag set in the CARD Reply 416 option to indicate that the message is the last for the associated 417 sequence number. An AR retransmitting replies to a CARD Request MUST 418 always send the full CARD Reply sequence. The Trusted Anchor sub- 419 option and the Router Certificate sub-option provide a means whereby 420 the MN can request specific certificates in a certification path, in 421 the event that the CARD Reply carrying a certification path spans 422 multiple messages and one of them is lost. However, a request for 423 specific certificates that were not received in the initial CARD 424 Reply MUST be treated as a new request by the MN and MUST use a 425 different sequence number. 427 Processing the Context-ID of Address sub-options allows the MN to 428 assign the resolved IP address of a specific CAR to a L2 ID. 430 In some cases a L2 ID parameter is present in a CARD Reply message. 431 The Status-Code field in the L2 ID parameter indicates one of the 432 following reasons for being sent towards the MN. 434 RESOLVER ERROR Status-Code indication: 436 In case the MN's current AR could not resolve a particular L2 ID, 437 this status code is returned to the MN. 439 MATCH Status-Code indication: 440 If a L2 ID is encountered that shares a CAR with a previously 441 resolved L2 ID, the AR returns MATCH to the MN. This status code is 442 an indicator that the Context-ID of this particular L2 ID sub-option 443 has been set to the Context-ID of the associated CAR's Address and 444 Capability Container sub-option, which is sent with this CARD Reply 445 message. This approach avoids sending the same CAR's address and 446 capability information multiple times with the same CARD Reply 447 message in case two or more L2 IDs resolve to the same CAR. A MN 448 uses the Context-ID received in the L2 ID sub-option as the key to 449 find the serving CAR of the given AP from the content of the 450 received CARD Reply message. 452 CANDIDATE Status-Code indication: 453 In case the MN does not append any L2 ID to the CARD Request, the AR 454 sends back the L2 ID and address information of all CARs. Since the 455 received parameters' Context-IDs cannot be correlated with a L2 ID's 456 Context-ID of a previously sent request, the AR chooses values for 457 the Context-ID and marks these candidate L2 IDs with CANDIDATE in 458 the status code of the distributed L2 IDs. However, individual 459 values of L2 IDs' Context-ID allow the MN to assign a particular L2 460 ID to the associated Address and the possibly received Capability 461 Container sub-option. 463 As described in Section 4.5, a MN can use CARD when it boots up 464 initially to determine whether piggyback operation is possible. A MN 465 can also use CARD initially to determine the capabilities and 466 certificates for an AR on which it boots up, or if it cannot obtain 467 the certificates beforehand. To do this, the MN includes a L2 468 Identifier option with its current AP L2 ID, and the requested 469 information. The AR replies with its own information. 471 4.2.2 Current Access Router Operation 473 Upon receipt of a MN's MN-AR CARD Request, the connected AR SHALL 474 resolve the requested APs' L2 ID to the IP address of the associated 475 CAR(s). In case no L2 ID parameter has been sent with the MN-AR CARD 476 Request message, the receiving AR retrieves all CARs' IP addresses, 477 and, if the C-flag was set in the request, the capability 478 information. 480 In the first case, where the AR resolves only requested L2 IDs, the 481 AR does not send back the L2 ID to the requesting MN. If, however, 482 two or more L2 IDs match the same CAR information, the L2 ID sub- 483 option is sent back to the MN, indicating MATCH in the Status-Code 484 field of the L2 ID. Furthermore, the AR sets the Context-ID of the 485 returned L2 ID to the value of the resolved CAR's L2 ID, Address and 486 Capability Container sub-option. In case an AR cannot resolve a 487 particular L2 ID, a L2 ID sub-option is sent back to the MN, 488 indicating RESOLVER ERROR in the L2 ID sub-option's Status-Code 489 field. 491 In the second case, where the AR did not receive any L2 ID with a 492 CARD Request, all candidate APs' L2 IDs are sent to a requesting MN 493 with the CARD Reply message. Here, the AR marks the Status-Code of 494 individual L2 IDs as CANDIDATE, indicating to the MN, that the 495 associated Context-ID cannot be matched with the ID of a previously 496 sent request. 498 In any case, the AR MUST set the Context-ID of the Address and the 499 Capability Container sub-option to the same value of the associated 500 L2 ID sub-option. 502 Optionally, when allowed by local policies and supported by 503 respective ARs for capability discovery, the AR MAY retrieve a 504 subset of capabilities or CARs, satisfying the optionally appended 505 Preferences and Requirement message parameter, from its local CAR 506 table. CARs' address information along with associated capabilities 507 are then delivered to the MN using the MN-AR CARD Reply message. The 508 CARs' IP address as well as the capabilities SHALL be encoded 509 according to the format for CARD protocol message parameters as 510 defined in Section 5.1.3 of this document. The capabilities are 511 encoded as attribute-value pairs, which are encapsulated in a 512 Capability Container message parameter according to the format 513 defined in Section 5.1.3.4. The responding current AR SHALL copy the 514 sequence number received in the MN-AR CARD Request to the MN-AR CARD 515 Reply. 517 4.3 Current Access Router - Candidate Access Router Operation 519 4.3.1 Current Access Router Operation 521 The MN's current AR MAY initiate capability exchange with CARs 522 either when it receives a MN-AR CARD Request or when it detects that 523 one or multiple of its local CAR table's capability entries' 524 lifetime is about to expire. An AR SHOULD preferentially utilize its 525 CAR table to fulfill requests rather than signaling the CAR 526 directly, and it SHOULD keep the CAR table up to date for this 527 purpose, in order to avoid injecting unnecessary delays into the MN 528 response. 530 The AR SHOULD issue an AR-AR CARD Request to the respective CAR(s) 531 if complete capability information of a CAR is not available in the 532 current AR's CAR table, or if such information is expired or about 533 to expire. The AR-AR CARD Request message format is defined in 534 Section 5.2.2. The sequence number on the AR-AR interface starts 535 with zero when the AR reboots. The sending AR MUST increment the 536 sequence number in the CARD Request by one each time it sends a CARD 537 Request message. 539 The AR MAY append its own capabilities, which are encoded as 540 attribute-value pairs and encapsulated with the Capability Container 541 message parameter, to the released AR-AR CARD Request. In case the 542 AR-AR CARD Request conveys the current AR's capabilities to the CAR, 543 the associated Capability Container can have any value set for the 544 Context-ID, since there is no need for the receiving CAR to process 545 this field due to the absence of a L2 ID and an Address sub-option. 546 Furthermore, the current AR MAY set the P-flag in the Capability 547 Container sub-option to inform the CAR about its own capability to 548 perform CARD protocol message piggybacking. 550 Optionally, a current AR MAY append the Preferences sub-option to 551 the AR-AR CARD Request to obtain only capability parameters of 552 interest from a CAR. 554 Upon receipt of the AR-AR CARD Reply, which has been sent by the CAR 555 in response to the previously sent request, the MN's current AR 556 SHALL extract the capability information from the payload of the 557 received message and store the received capabilities in its local 558 CAR table. The lifetime of individual capabilities is to be set 559 according to the lifetime indicated for each capability received. 560 The value of the table entries' timeout shall depend upon the nature 561 of individual capabilities. 563 Optionally, CARs can send unsolicited CARD Reply messages to 564 globally adjacent ARs if the configuration of their APs or 565 capabilities changes dynamically. In case the current AR receives an 566 unsolicited CARD Reply message from a CAR for which there is an 567 entry in its local CAR table, the current AR checks that the 568 sequence number of the received CARD Reply has increased compared to 569 the previously received unsolicited CARD Reply message, which has 570 been sent from the same CAR. Then, the current AR can update its 571 local CAR table according to the received capabilities. If a new CAR 572 is added, an AR may receive a CARD Reply from a CAR that is not in 573 its CAR table, or from a CAR that has rebooted. In this case, the 574 sequence number is 0. The requirement that ARs share an IPsec 575 security association, detailed in Section 6, ensures that an AR 576 never accepts CARD information from an unauthenticated source. 578 4.3.2 Candidate Access Router Operation 580 Upon receipt of an AR-AR CARD Request, a CAR shall extract the 581 sending AR's capabilities, if the sending AR has included its 582 capabilities. The CAR SHALL store the received capabilities in its 583 CAR table and set the timer for individual capabilities 584 appropriately. The value of the table entries' timeout depends upon 585 the nature of capabilities in the AR-AR CARD Reply message. The CAR 586 must include the same sequence number in the AR-AR CARD Reply 587 Message as received in the AR-AR CARD Request Message. The AR-AR 588 CARD Reply shall include the CAR's capabilities as list of 589 attribute-value pairs in the Capability Container message parameter. 590 In case the sending AR has appended an optional Preferences sub- 591 option, the CAR MAY perform capability filtering and send back only 592 these capabilities, which are of interest to the requesting AR, 593 identified according to the Preferences sub-option. Since the AR-AR 594 CARD Reply is based on a previously received AR-AR CARD Request, the 595 CAR MUST set the U-flag of the AR-AR CARD Reply to 0. 597 Optionally, the CAR MAY send an unsolicited CARD Reply message to 598 globally adjacent ARs in case one or more of its capability 599 parameters change. The unsolicited CARD Reply messages should have 600 as destination address the adjacent ARs' unicast address and must 601 have the U-flag set. Consecutive unsolicited CARD Reply messages 602 MUST have the sequence number incremented respectively, starting 603 with 0 when the AR boots. 605 4.4 CARD Protocol Message Piggybacking on the MN-AR Interface 607 CARD supports another mode of CAR information distribution, in which 608 the capabilities are distributed piggybacked on fast handover 609 protocol messages. To allow MNs and ARs appending the ICMP-option 610 type CARD Request and CARD Reply (Section 5.1.2) to the ICMP-type 611 Fast Mobile IPv6 [Kood03] signaling messages, the MN and AR should 612 know about the signaling peer's capability for CARD protocol message 613 piggybacking. This requires dynamic discovery of piggybacking 614 capability using the P-flag in the MN-AR CARD Request and the MN-AR 615 CARD Reply message, as well as in the Capability Container message 616 parameter. The format of these messages and parameters is described 617 in Section 5.1. 619 The MN sends the very first CARD Request to its current AR using the 620 ICMP-type CARD main header for transport, as described in Section 621 4.2.1. In case the MN supports CARD protocol message piggybacking, 622 the P-flag in this very first CARD Request message is set. On 623 reception of the CARD Request message, current AR learns about the 624 MN's piggybacking capability. To indicate its piggybacking 625 capability, the AR sets the P-flag in the CARD Reply message. In 626 case the AR does not support piggybacking, all subsequent CARD 627 protocol messages between the MN and the AR are sent stand-alone, 628 using the CARD main header. In case both nodes, the MN and its 629 current AR, support CARD protocol message piggybacking, subsequent 630 CARD protocol messages can be conveyed as an option via the Fast 631 Mobile IPv6 Router Solicitation for Proxy (RtSolPr) and Proxy Router 632 Advertisement (PrRtAdv) messages. During the CARD process, a MN 633 learns about CAR's piggybacking capability during the discovery 634 phase, since the Capability Container, as described in Section 635 5.1.3.4, also carries a P-flag. This allows the MN to immediately 636 perform CARD protocol message piggybacking after a handover to a 637 selected CAR, assumed this CAR supports CARD protocol piggybacking. 639 If a MN prefers the reverse address translation function of the Fast 640 Mobile IPv6 protocol, it can use CARD protocol message piggybacking 641 to retrieve only the CARs' capability information. To indicate that 642 reverse address translation is not required, the piggybacked CARD 643 Request message MUST have the A-flag set. These causes the current 644 AR to append only Capability Container sub-options. To associate a 645 Capability Container, sent as a parameter of the CARD Reply message, 646 to the IP address for the appropriate CAR, the Context-ID of an 647 individual Capability Container MUST be used as an index, pointing 648 to the associated IP address in the PrRtAdv message options. The 649 Context-ID of individual Capability Containers is set appropriately 650 by the MN's current AR. Details about how individual Context-ID 651 values can be associated with a particular IP address option of the 652 PrRtAdv message is out of the scope of this document. 654 5. PROTOCOL MESSAGES 656 5.1 CARD Messages for the Mobile Node-Access Router Interface 658 5.1.1 MN-AR Transport 660 The MN-AR interface uses ICMP for transport. Because ICMP messages 661 are limited to a single packet, and because ICMP contains no 662 provisions for retransmitting packets if signaling is lost, the CARD 663 protocol incorporates provisions for improving transport performance 664 on the MN-AR interface. MNs SHOULD limit the amount of information 665 requested in a single ICMP packet, since ICMP has no provision for 666 fragmentation above the IP level. 668 Hosts and Access Routers use the Experimental ICMP type main header 669 [Ke04] when CARD protocol messages cannot be conveyed via ICMP-type 670 Fast Mobile IPv6 [Kood03]. The MN-AR interface MUST implement and 671 SHOULD use the CARD ICMP Type header for transport. If available, 672 the MN-AR interface MAY use the ICMP-type Fast Mobile IPv6 [Kood03] 673 for transport (Section 4.4). 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Type | Code | Checksum | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Subtype | Reserved | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Options ... 683 +-+-+-+-+-+-+-+-+-+-+-+- - - - 685 IP Fields: 687 Source Address: 688 An IP address assigned to the sending 689 interface. 691 Destination Address: 692 An IP address assigned to the receiving 693 interface. 695 Hop Limit: 255 697 ICMP Fields: 699 Type Experimental Mobility type (To be assigned by 700 IANA for IPv4 and IPv6, see [Ke04]). 702 Code 0 704 Checksum The ICMP checksum. 706 Subtype Experimental Mobility subtype for CARD, see 707 [Ke04]. 709 Reserved This field is currently unused. It MUST be 710 initialized to zero by the sender and MUST be 711 ignored by the receiver. 713 Valid Options: 715 CARD Request: The CARD Request allows entities to request CARD 716 specific information from ARs. To support 717 processing the CARD Request message on the 718 receiver side, further sub-options may be 719 carried, serving as input to the reverse address 720 translation function and/or capability discovery 721 function. 723 CARD Reply: The CARD Reply carries parameters, previously 724 requested with a CARD Request, back to the 725 sender of the CARD Request. 727 Valid Sub-Options: 729 Support level indicated in parentheses: 731 Layer-2 ID (mandatory): 732 The Layer-2 ID sub-option [5.1.3.1] carries 733 information about the type of an access point 734 as well as the Layer-2 address of the access 735 point associated with the CAR, whose IP address 736 and capability information is to be resolved. 738 Capability container (mandatory): 739 The Capability container sub-option carries 740 information about a single CAR's capabilities. 741 The format of this sub-option is described in 742 Section 5.1.3.4. 744 Address (mandatory): 745 The Address sub-option carries information on 746 an individual CAR's resolved IP address. The 747 format of the Address sub-option is described 748 in Section 5.1.3.5. 750 Trusted Anchor (mandatory): 751 The Trusted Anchor sub-option carries the name 752 of a trusted anchor for which the MN has 753 a certificate. The format of the Trusted Anchor 754 sub-option is described in Section 5.1.3.6. 756 Router Certificate (mandatory): 757 The Router Certificate sub-option carries one 758 certificate in the path for the AR or for a 759 CAR. The chain includes certificates starting 760 at a trusted anchor, which the router shares in 761 common with the mobile node, to the router 762 itself. The format of the Router Certification 763 sub-option is described in Section 5.1.3.7. 765 Preferences sub-option (optional): 766 The Preferences sub-option carries information 767 about attributes of interest to the requesting 768 entity. Attributes are encoded according to the 769 AVP encoding rule as described in Section 770 5.1.4. For proper settings of AVP Code and Data 771 field, see Section 5.1.3.2. This sub-option is 772 used only in case of performing optional 773 capability pre-filtering on ARs and provides 774 only capabilities of interest to a requesting 775 MN. 777 Requirements (optional): 778 The Requirements sub-option carries information 779 about attribute-value pairs required for pre- 780 filtering of CARs on a MN's current AR. This 781 parameter conveys MN specific attribute-value 782 pairs to allow a MN's current AR to send only 783 information about CARs of interest back to the 784 requesting MN. CARs are filtered on ARs 785 according to CARs' capability parameters and 786 given policy or threshold, as encoded in the 787 Requirements sub-option. Attribute-value pairs 788 are encoded according to the AVP encoding rule 789 as described in Section 5.1.4. Rules for proper 790 setting of the AVP Code and Data field for the 791 Requirements sub-option are described in 792 Section 5.1.3.3. 794 CARD Requests which fail to elicit a response are retransmitted. 795 The initial retransmission occurs after a CARD_REQUEST_RETRY wait 796 period. Retransmissions MUST be made with exponentially increasing 797 wait intervals (doubling the wait each time). CARD Requests should 798 be retransmitted until either a response (which might be an error) 799 has been obtained, or for CARD_RETRY_MAX seconds occurs. ARs MUST 800 discard any CARD Requests having the same sequence number after 801 CARD_RETRY_MAX seconds. If a CARD Reply spans multiple ICMP 802 messages, the same sequence number MUST be used in each message. 804 MNs which retransmit a CARD Request use the same CARD sequence 805 number. This allows an AR to cache its reply to the original request 806 and then send it again, should a duplicate request arrive. This 807 cached information should only be held for a maximum of 808 CARD_RETRY_MAX seconds after receipt of the request. Sequence 809 numbers SHOULD be randomly chosen. Random sequence numbers avoid 810 duplicates if MNs restart frequently, and simplify sequence number 811 maintenance on both the MN and AR when MNs frequently appear and 812 disappear due to movement between CARs. 814 5.1.2 CARD Options Format 816 All options are of the form: 818 0 1 2 3 819 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 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Type | Length |Vers.| ... | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 ~ ... ~ 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 Fields: 828 Type: 8-bit identifier of the type of option, 829 assigned by IANA. See [Ke04] for CARD Request 830 and CARD Reply values. 832 Length: 8-bit unsigned integer. The length of 833 option including the type and length fields in 834 units of 8 octets. The value 0 is invalid. 836 Vers.: 3-bit version code. For this specification, 837 Vers.=1. 839 5.1.2.1 CARD Request Option 841 0 1 2 3 842 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 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Type | Length |Vers.|P|C|A|T| Reserved | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Sequence Number | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Sub-Options 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 851 Fields: 853 Type: To be assigned by IANA for IPv4 and IPv6, see [Ke04]. 855 Length: The length of the option in units of 8 octets, including 856 the type and length fields as well as sub-options. 858 Vers.: 3-bit version code. For this specification, 859 Vers.=1. 861 Flags: P-flag: Indicates CARD protocol message piggybacking 862 capability of the CARD Request message sender. 863 A description for proper use of this flag can 864 be found in Section 4.4 of this document. 866 C-flag: Indicates that the requesting entity is 867 interested also in associated CARs' 868 capabilities. If the MN wants the AR to append 869 CARs' capability parameters to the CARD Reply 870 in addition to address information, the MN must 871 set this flag. 873 A-flag: Indicates that the requesting entity does NOT 874 want the receiver of this message to perform 875 reverse address translation. This flag is 876 set in case CARD protocol messages are 877 piggybacked with a protocol that performs 878 reverse address translation. For details refer 879 to Section 4.4 of this document. 881 T-flag: Indicates that the requesting entity is 882 interested in obtaining all certificates from 883 the responder. This flag is only valid on the 884 AR-AR interface. 886 The flag combination A=1 and C=0 is invalid, and the 887 flag T=1 is invalid on the MN-AR interface. The AR MUST 888 discard an invalid message and log an appropriate error 889 message. 891 Reserved: Initialized to zero, ignored on reception. 893 Sequence Number: 894 Allows correlating requests with replies. 896 Valid Sub-Options: 898 - L2 ID sub-option 899 - Preferences sub-option 900 - Requirements sub-option 901 - Trusted Anchor sub-option 903 To ensure meeting requirements on boundary alignment, individual 904 sub-options MUST meet the 64-bit boundary alignment requirements 905 respectively. This will ensure that the entire CARD Request option 906 meets the 8n alignment constraint. 908 5.1.2.2 CARD Reply Option 910 0 1 2 3 911 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 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Type | Length |Vers.|P|U|L| Reserved | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Sequence Number | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Sub-Options 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 920 Fields: 922 Type: To be assigned by IANA for IPv4 and IPv6 [Ke04]. 924 Length: The length of the option in units of 8 octets, including 925 the type and length fields as well as sub-options. 927 Vers.: 3-bit version code. For this specification, 928 Vers.=1. 930 Flags: P-flag: Indicates CARD protocol message piggybacking 931 capability of the CARD Reply message sender. 932 A description for proper use of this flag can 933 be found in Section 4.5 of this document. 935 U-flag: Indicates an unsolicited CARD Reply. This flag 936 is only valid on the AR-AR interface. 938 L-flag: Set if this message is the last message in a 939 a multiple ICMP message reply. This flag is only 940 valid on the MN-AR interface. 942 The flag U=1 on an AR-MN message is invalid. An invalid 943 message should be discarded and an appropriate error 944 message logged. 946 Reserved: Initialized to zero, ignored on reception. 948 Sequence Number: 949 Allows correlating requests with replies. 951 Valid Sub-Options: 953 - L2 ID sub-option 954 - Capability Container sub-option 955 - Address sub-option 956 - Router Certificate sub-option. 958 To ensure meeting requirements on boundary alignment, individual 959 sub-options MUST meet 64-bit boundary alignment requirements 960 respectively. This will ensure that the entire CARD Request option 961 meets the 8n alignment constraint. 963 5.1.3 Sub-Options Format 965 All sub-options are of the form: 967 0 1 2 3 968 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 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 |Sub-Option Type|Sub-Option Len | Sub-Option Data . . . 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 Sub-Option Type: 8-bit identifier of the type of option. The 974 sub-options defined in this document are listed 975 in the table below. The table also indicates 976 on which interfaces the sub-option is valid. 978 Description Type Interface 979 | | / \ 980 | | MN-AR AR-AR 981 --------------------------------------------------------------- 982 L2 ID 0x01 x 983 Address 0x02 x 984 Capability Container 0x03 x x 985 Preferences 0x04 x x 986 Requirements 0x05 x 987 Trusted Anchor 0x06 x 988 Router Certificate 0x07 x x 990 Sub-Option-Length: 8-bit unsigned integer, indicating the length 991 of the sub-option, including sub-option type and 992 sub-option length fields. Sub-option lengths are 993 in units of 8 octets, aligned on a 64-bit 994 boundary. Sub-options that are shorter are 995 padded with null octets, the extent of the 996 padding is determined by the sub-option contents. 998 5.1.3.1 L2 ID Sub-Option 1000 0 1 2 3 1001 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 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 |Sub-Option Type|Sub-Option Len | Context-ID | Status Code | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | L2-Type | L2 ID . . . 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 1008 Sub-Option Type: 1009 0x01 1011 Sub-Option Length: 1012 Length of the sub-option. 1014 Context-ID: Associates the L2 ID, IP address and other parameters 1015 that belong to the same AR IP address but are encoded 1016 in separate sub-options. 1018 Status Code: This field allows ARs to inform a requesting entity 1019 about processing results for a particular L2 ID. The 1020 L2 ID sub-option MUST be sent back to the requesting 1021 entity with a CARD Reply message. 1023 The following status codes are specified: 1025 0x00: NONE - This value MUST be set when the 1026 L2 ID is included in a CARD Request. 1028 0x01: CANDIDATE - MUST be set in a CARD Reply when 1029 a L2 ID sub-option is included with 1030 information about candidate APs' L2 IDs. 1031 Candidate L2 IDs are sent if the CARD Request 1032 did not include a specific L2 ID for 1033 resolution. If CANDIDATE is set, the AR MUST 1034 set the Context-ID field of individual 1035 parameters to a value that allows matching 1036 associated L2 ID, address and capability 1037 information on the receiver side. 1039 0x02: MATCH - MUST be set in the CARD Reply to 1040 identify that this L2 ID matches previously 1041 resolved CAR information for a different L2 1042 ID. If MATCH is set, the AR sets the Context- 1043 ID in the L2-ID sub-option to identify the 1044 matching previously resolved L2 ID. 1046 0x03: RESOLVER ERROR - MUST be set in the CARD 1047 Reply if the L2 ID cannot be resolved. The AR 1048 sets this value for the Status Code in the 1049 returned L2 ID sub-option. 1051 L2 type: Indicates the interface type. Allocated by IANA 1052 [Ke04]. 1054 L2 ID: The variable length Layer-2 identifier of an 1055 individual CAR's access point. The length without 1056 padding is determined by the L2 type. 1058 5.1.3.2 Preferences Sub-Option 1060 0 1 2 3 1061 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 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 |Sub-Option Type|Sub-Option Len | Preferences 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 Sub-Option Type: 1067 0x04 1069 Sub-Option Length: 1070 Length of the sub-option. 1072 Preferences: List of capability attribute values (Section 5.1.4). 1074 Only ATTRIBUTE (AVP Code, see Section 5.1.4) fields MUST be present 1075 and set for individual capabilities, which are of interest to the 1076 requesting entity. The LIFETIME and VALUE (Data) indicator will not 1077 be processed and can be omitted. The AVP LENGTH indicator is also 1078 not present, since the preferences are indicated only with a list of 1079 16-bit encoded ATTRIBUTE fields. In case 64-bit boundary alignment 1080 requirements cannot be met with the list of ATTRIBUTE values, 1081 padding the missing 16-bit MUST be done with an ATTRIBUTE value of 1082 0x0000. An ATTRIBUTE code of 0x0 is reserved, so the end of the 1083 ATTRIBUTE code list can be determined when an ATTRIBUTE value of 0x0 1084 is read. 1086 The use of the Preferences sub-option is optional and for 1087 optimization purposes. 1089 5.1.3.3 Requirements Sub-Option 1091 0 1 2 3 1092 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 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 |Sub-Option Type|Sub-Option Len | Requirements 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 Sub-Option Type: 1098 0x05 1100 Sub-Option Length: 1101 Length of the sub-option. 1103 Requirements: AVP encoded requirements (see Section 5.1.4) 1105 AVPs MUST be encoded according to the rule described in Section 1106 5.1.4. Both, the ATTRIBUTE (AVP Code) and VALUE (Data) field MUST be 1107 present and set appropriately. The end of the Requirements list can 1108 be determined when an ATTRIBUTE value of 0x0 is read. 1110 The use of the Requirements sub-option is optional and for 1111 optimization purpose. 1113 5.1.3.4 Capability Container Sub-Option 1115 0 1 2 3 1116 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 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 |Sub-Option Type|Sub-Option Len | Context-ID |P| Reserved | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | AVPs 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 1123 Sub-Option Type: 1124 0x03 1126 Sub-Option Length: 1127 Length of the sub-option. 1129 Context-ID: Associates the L2 ID, IP address and other parameters 1130 that belong to the same AR IP address but are encoded 1131 in separate sub-options. 1133 Flags: P-flag: Indicates piggybacking capability of the CAR 1134 whose capabilities are conveyed in this 1135 Capability Container. This flag allows a MN 1136 to know after a CARD process whether a 1137 selected new AR can perform piggybacking. 1139 Reserved: Initialized to zero, ignored on reception. 1141 AVPs: AVPs are a method of encapsulating capability 1142 information relevant for the CARD protocol. See 1143 Section 5.1.4 for the AVP encoding rule and list 1144 parsing. 1146 5.1.3.5 Address Sub-Option 1148 0 1 2 3 1149 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 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 |Sub-Option Type|Sub-Option Len | Context-ID | Address Type | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Address . . . 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - 1156 Sub-Option Type: 1157 0x02 1159 Sub-Option Length: 1160 Length of the sub-option. For IPv4, the length is 1161 1 (8 octets); for IPv6 the length is 3 (24 octets). 1163 Context-ID: Associates the L2 ID, IP address and other parameters 1164 that belong to the same AR IP address but are encoded 1165 in separate sub-options. 1167 Address Type: Indicates the type of the address. 1169 0x01 IPv4 1170 0x02 IPv6 1172 Address: The Candidate Access Router's IP address. 1174 5.1.3.6 Trusted Anchor Sub-Option 1176 0 1 2 3 1177 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 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 |Sub-Option Type|Sub-Option Len | Component | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Trusted Anchor Name 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - 1184 Sub-Option Type: 1185 0x06 1187 Sub-Option Length: 1188 Length of the sub-option. 1190 Reserved: Initialized to zero, ignored on reception. 1192 Component: 1193 A 2 octet unsigned integer field set to 65,535 if the 1194 sender desires to retrieve all the certificates in 1195 the certification path. Otherwise, it is set to the 1196 component identifier corresponding to the certificate 1197 that the receiver wants to retrieve. 1199 Trusted Anchor Name: DER encoding for the X.501 name of 1200 certification path component(see [Arkko04] for 1201 more detail on certification path component 1202 name encoding). 1204 A CARD Request message containing Trusted Anchor sub-options MUST 1205 NOT contain any other sub-options, except for a single L2 ID sub- 1206 option identifying the AP of interest. 1208 Trusted anchor sub-options SHOULD be retransmitted for individual 1209 components not received within CARD_REQUEST_RETRY seconds, rather 1210 than retransmitting a request for the whole list. Subsequent 1211 retransmissions SHOULD take into account any received options and 1212 only request those that have not been received. 1214 5.1.3.7 Router Certificate Sub-Option 1216 0 1 2 3 1217 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 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 |Sub-Option Type|Sub-Option Len | Context-ID | Reserved | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | All Components | Component | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 | | 1224 + + 1225 | Certificate... | 1226 + + 1227 | | 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 | Padding... | 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 Sub-Option Type: 1233 0x07 1235 Sub-Option Length: 1236 Length of the sub-option. 1238 Context-ID: Associates the L2 ID, IP address and other parameters 1239 that belong to the same AR IP address but are encoded 1240 in separate sub-options. 1242 Reserved: Initialized to zero, ignored on reception. 1244 All Components: 2 octet unsigned integer giving the total number of 1245 certificates in the certification path. 1247 Component: 2 octet unsigned integer giving the location of this 1248 certificate in the certification path. 1250 Certificate: Variable length field containing the X.509v3 router 1251 certificate encoded in ASN.1 (see [Arkko04] for more 1252 detail on certificate profile including encoding) 1254 Padding: A variable length field making the option length a 1255 multiple of 8, beginning after the ASN.1 encoding of 1256 the certificate continuing to the end of the option, 1257 as specified by the Length field. 1259 A CARD Reply containing a Router Certificate sub-option MUST NOT 1260 include more than one such sub-option, and the CARD Reply MUST 1261 contain the matching L2 ID sub-option and router Address sub-option 1262 for the router possessing the chain with the Context-ID field set to 1263 a nonzero value, and no other sub-options. Any other sub-options 1264 included in a CARD Reply SHOULD be ignored. If the reply spans 1265 multiple ICMP messages, the L2 ID sub-option and router Address sub- 1266 option MUST be included in the first message sent, and the Context- 1267 ID field in the Router Certificate sub-options in all the messages 1268 MUST be set to the same value as in the L2 ID and Address sub- 1269 options. The replying AR SHOULD order the returned certification 1270 path such that the certificate immediately after the trust anchor in 1271 the path is the first certificate sent, in order to allow immediate 1272 verification. The trust anchor certificate itself SHOULD NOT be 1273 sent. 1275 5.1.4 Capability AVP encoding rule 1277 0 1 2 3 1278 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 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 | AVP Code | AVP Length | Reserved | 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 | Attribute Lifetime | Data . . . 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 1285 AVP Code: Identifies the attribute uniquely. The AVP Code 1286 0x0000 is reserved and MUST NOT be assigned to a 1287 capability. 1289 AVP Length: The two octet AVP length field indicates the 1290 number of octets in this AVP, including the AVP Code, 1291 AVP Length, Reserved, Lifetime and Data field. 1293 Reserved: Initialized to zero, ignored on reception. 1295 Lifetime: Specifies the lifetime of the encoded capability 1296 in seconds. In case of a static capability, the 1297 Lifetime field MUST be set to the maximum value 1298 (0xffff), which indicates that the lifetime of this 1299 capability parameter never expires. A lifetime value 1300 of 0x0000 deletes a capability entry. 1302 Data: This variable length field has the Value of the 1303 capability attribute encoded. 1305 Since an AVP Code of 0x0 is reserved, it can be used by the sub- 1306 option list parsing to determine when the end of a list of 1307 Capabilities has been reached and where the sub-option padding 1308 starts. AVPs themselves are not zero padded. 1310 Note: This document provides no detailed information on how to 1311 encode the individual capability attribute values, which is to be 1312 encoded in the Data field. Details on the interpretation of 1313 individual capability parameters are out of scope of this document. 1315 5.2 CARD Inter-Access Router Messages 1317 5.2.1 AR-AR Transport 1319 Since the types of access networks in which CARD might be useful are 1320 not today deployed or, if they have been deployed, have not been 1321 extensively measured, it is difficult to know whether congestion 1322 will be a problem for inter-router CARD. Part of the research task 1323 in preparing CARD for consideration as a candidate for possible 1324 standardization is to quantify this issue. However, in order to 1325 avoid potential interference with production applications should a 1326 prototype CARD deployment involve running over the public Internet, 1327 it seems prudent to recommend a default transport protocol that 1328 accommodates congestion. 1330 This suggests that implementations of CARD MUST support and 1331 prototype deployments of CARD SHOULD use Stream Control Transport 1332 Protocol (SCTP) [Stew00] for the transport protocol between routers, 1333 especially if deployment over the public Internet is contemplated. 1334 SCTP supports congestion control, fragmentation, and partial 1335 retransmission based on a programmable retransmission timer. SCTP 1336 also supports many advanced and complex features, such as multiple 1337 streams and multiple IP addresses for failover, that are not 1338 necessary for experimental implementation and prototype deployment 1339 of CARD. The use of such SCTP features for CARD is not recommended 1340 at this time. 1342 The SCTP Payload Data Chunk carries the CARD messages. CARD messages 1343 on the inter-router interface consist of just the CARD Request or 1344 CARD Reply options. The User Data part of each SCTP message contains 1345 the CARD option for the message type. For instance, a CARD Reply 1346 message is constructed by including the CARD Reply option and all 1347 the appropriate sub-options within the User Data part of an SCTP 1348 message. 1350 A single stream is used for CARD with in-sequence delivery of SCTP 1351 messages. Each message, unless fragmented, corresponds to a single 1352 CARD query or response. Unsolicited CARD Reply messages can also be 1353 sent to peers to notify them of changes in network configuration or 1354 capabilities. A single stream provides simplicity. Use of multiple 1355 streams to prevent head-of-line blocking is for future study. Since 1356 timeliness is not an issue with inter-router CARD and since there is 1357 unlikely to be more than one CARD transaction between two routers 1358 active at any one time, having ordered delivery simplifies the 1359 implementation. The Payload Protocol Identifier in the SCTP header 1360 is 'CARD'. CARD uses the Seamoby SCTP port number [Ke04]. 1362 The format of Payload Data Chunk taken from [Stew00] is shown in the 1363 following diagram. 1365 0 1 2 3 1366 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 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | Type = 0 | Reserved|U|B|E| Length | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | TSN | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 | Stream Identifier S | Stream Sequence Number n | 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 | Payload Protocol Identifier | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 \ \ 1377 / User Data (seq n of Stream S) / 1378 \ \ 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 'U' bit The Unordered bit. MUST be set to 0 (zero). 1382 'B' bit The Beginning fragment bit. See [Stew00]. 1384 'E' bit The Ending fragment bit. See [Stew00]. 1386 TSN Transmission Sequence Number. See [Stew00]. 1388 Stream Identifier S 1389 Identifies the CARD stream. 1391 Stream Sequence Number n 1392 Sequence number. See [Stew00]. 1394 Payload Protocol Identifier 1395 Set to 'CARD'. 1397 User Data Contains the CARD message. 1399 In order to avoid generating congestion on startup, ARs MUST wait a 1400 random amount of time between 0 and CARD_STARTUP_WAIT seconds upon 1401 reboot before sending an AR-AR CARD Request to one of its CARs. An 1402 AR that receives a CARD Request from an AR that is not in its CAR 1403 table MUST NOT solicit the AR, but rather MUST wait until the AR 1404 sends an unsolicited CARD Reply advertising the AR's information. An 1405 AR that is starting up MUST sent unsolicited CARD Replies to all its 1406 CARs to make sure their CAR tables are properly populated. 1408 The frequency of unsolicited CARD Reply messages MUST be strictly 1409 limited to CARD_MIN_UPDATE_INTERVAL, in order to avoid overwhelming 1410 CARs with traffic. ARs are free to discard messages that arrive more 1411 frequently. 1413 If a CARD deployment will never run over the public Internet, and it 1414 is known that congestion is not a problem in the access network, 1415 alternative transport protocols MAY be appropriate vehicles for 1416 experimentation. Implementations of CARD MAY support UDP for such 1417 purposes. In that case, the researcher MUST be careful to 1418 accommodate good Internet transport protocol engineering practices, 1419 including using retransmits with exponential backoff, etc. In 1420 addition, it is an open research question whether SCTP is an 1421 appropriate transport protocol for all inter-router CARD operations. 1422 Investigation of this issue, for example to determine whether a 1423 lighter weight protocol might be more appropriate than SCTP, may be 1424 of interest to some researchers. 1426 5.2.2 Protocol Payload Types 1428 The AR-AR interface MUST insert the CARD Request option and CARD 1429 Reply option directly in the body of the SCTP User Data field. The 1430 sequence number for the CARD Request on the AR-AR interface MUST be 1431 initialized to zero when the AR reboots, and MUST be incremented 1432 every time a CARD Request message is sent. The replying AR MUST 1433 include a sequence number from the CARD Request in the CARD Reply. 1434 If an unsolicited CARD Reply is sent, the sending AR MUST increment 1435 the sequence number. Sequentially increasing sequence numbers allows 1436 the receiving AR to determine whether the information has already 1437 been received. 1438 On the AR-AR interface, the Capability Container parameter is used 1439 to convey capabilities between ARs. Optionally, the Preferences 1440 parameter can be used for capability pre-filtering during the inter- 1441 AR capability discovery procedure. Payload types and encoding rules 1442 are the same as described for the respective sub-option types in 1443 Section 5.1 for the MN-AR interface. The same TLV-encoded format is 1444 used to attach the options as payload to the protocol main header. 1445 Additionally, an AR can set the T flag in the CARD Request header in 1446 order to obtain the certificates for the CAR. The description of 1447 sub-options in Section 5.1.3 includes information on what flag 1448 settings are prohibited on the AR-AR interface. 1450 6. SECURITY CONSIDERATIONS 1452 6.1 Veracity of CARD Information 1454 The veracity of the CARD protocol depends on the ability of an AR to 1455 obtain accurate information about geographically neighboring ARs, 1456 and to provide such accurate information about its own APs and 1457 capabilities to other ARs. The CARD protocol described in the body 1458 of this document does not contain any support for determining the AR 1459 to AP mapping or capabilities, either for a specific AR itself or 1460 for a CAR. Therefore, methods for determining the accuracy of the 1461 information exchanged between ARs are out of scope for the base CARD 1462 protocol. The appendices of this draft describe procedures for 1463 discovering the identities of the geographically adjacent ARs and 1464 APs, including capabilities, and discuss relevant security 1465 considerations. Alternatively, this information could be statically 1466 configured into the AR. 1468 6.2 Security Association between AR and AR 1470 CARD does contain support allowing ARs to exchange capability 1471 information. If this protocol is not protected from modification, a 1472 malicious attacker can modify the information. Also if the 1473 information is delivered in plain text, a third party can read it. 1475 To prevent the information from being compromised, the CARD messages 1476 between ARs MUST be authenticated. The messages also SHOULD be 1477 encrypted for privacy of the information if required. 1478 Confidentiality might be required if the traffic between two ARs in 1479 an operator's network traversed the public Internet, for example. 1481 Two ARs engaging in the CARD protocol MUST use IKE [HarCar98] to 1482 negotiate an IPsec ESP security association for message 1483 authentication. If confidentiality is desired, the two ARs MUST 1484 additionally negotiate an ESP security association for encryption. 1485 Replay protection SHOULD also be enabled with IKE. To protect CARD 1486 protocol messages between ARs, IPsec ESP [AtKe98] MUST be used with 1487 a non-null integrity protection and origin authentication algorithm 1488 and SHOULD be used with a non-null encryption algorithm for 1489 protecting the confidentiality of the CARD information. 1491 An AR can provide the certificates for its CARs if the certificates 1492 are available. The AR requests certificates from its CARs by setting 1493 the T flag in the CARD Request message. All certificates are sent. 1495 If CARD is used to exchange information between different 1496 administrative domains, additional security policy issues may apply. 1497 Such issues are out of scope of this document. Use of CARD between 1498 administrative domains is not recommended at this time, until the 1499 policy issues involved are more thoroughly understood. 1501 6.3 Security Association between AR and MN 1503 A malicious node can send bogus CARD Reply messages to MNs by 1504 masquerading as the AR. The MN MUST authenticate the CARD Reply 1505 messages from the AR. Since establishing an IPSec security 1506 association between the MN and AR is likely to be a performance 1507 issue, IKE is not an appropriate mechanism for setting up the 1508 security association. Instead, the SEND security association is used 1509 [Arkko04]. ARs MUST include a SEND Signature Option on CARD Reply 1510 messages. The format of the signature option is the same for both 1511 IPv4 and IPv6 CARD, though SEND itself is only defined for IPv6. A 1512 Mobile IPv4 ICMP Foreign Agent Advertisement option type code for 1513 the SEND signature option [Ke04] has been allocated. 1515 No authentication is required for CARD Requests since CARD 1516 information is provided by the AR to optimize link access. In 1517 contrast, CARD Reply authentication is required because a bogus AR 1518 could provide the MN with CARD information that would lead the MN to 1519 handover to a bogus router which could steal traffic or propagate a 1520 denial of service attack on the MN. The asymmetry of the 1521 authentication requirement is the same as that involving Router 1522 Advertisements in IPv6 router discovery [SEND]. 1524 Since CARD is a discovery protocol, confidentiality is not necessary 1525 in general on the MN-AR interface. In specific cases where different 1526 network operators are sharing the same access network 1527 infrastructure, network operators may want to hide information about 1528 operator-specific capabilities for business reasons. The base CARD 1529 protocol contains no support for such cases. However, should such a 1530 case arise in the future, an AVP for an encrypted capability can be 1531 defined at that time. 1533 6.4 Router Certificate Exchange 1535 Because SEND is only available in IPv6, the procedures for obtaining 1536 certificates differ depend on whether CARD is used with IPv4 or 1537 IPv6. In IPv6, when the MN receives a CARD reply with signature from 1538 a router for which it does not have a certificate, it SHOULD use 1539 SEND DCS/DCA to obtain the AR's certificate chain. ARs MUST be 1540 configured with a certification path for this purpose, and MNs MUST 1541 be configured with a set of certificates for shared trusted anchors 1542 to allow verification of the AR certificates. A MN may not 1543 necessarily need to use Cryptographically Generated Addresses (CGAs) 1544 with CARD, CGA support is OPTIONAL for CARD. A certificate profile 1545 for ARs is described in the SEND specification [Arkko04]. 1547 In IPv4, there is no DCS/DCA message for obtaining the certificate. 1548 In that case, if the MN does not have a certificate for the router, 1549 the MN sends a CARD Request message containing the L2 ID of its 1550 current AP and one Trusted Anchor sub-option (Section 5.1.3.6) for 1551 each shared trusted anchor for which the MN has a certificate, to 1552 obtain the certification path for the current AR. The Component 1553 field of the Trusted Anchor sub-option is set to 65535 to indicate 1554 that the entire certification path is needed. No other options 1555 should be included in the request. The AR replies by sending a CARD 1556 Reply containing the L2 ID sub-option sent in the request, an 1557 Address sub-option for itself and a Router Certificate sub-option 1558 (Section 5.1.3.7) containing one certificate in its certification 1559 path, matching one of the requested trust anchors, and no other sub- 1560 options, setting the Context-ID of all sub-options to match. The All 1561 Components field is set to the path length and the Component field 1562 is set to the number of this component in the path. If the path is 1563 longer than one certificate, the router sends the LD ID sub-option 1564 and the Address sub-option in the first certificate and the other 1565 certificates in separate ICMP messages, due to the limitation on 1566 ICMP message length, with the same Context-ID set on each Route 1567 Certificate sub-option, and the Component field properly set. The 1568 router SHOULD NOT send the trusted anchor's certificate and SHOULD 1569 send certificates in order from the certificate after the trusted 1570 anchor. If the trusted anchor option does not match any certificate, 1571 the AR returns the Trusted Anchor sub-options in the reply. The MN 1572 SHOULD immediately conduct a Certificate Revocation List (CRL) check 1573 on any certificates obtained through CARD certificate exchange, to 1574 make sure the certificates are still valid. 1576 Certification paths for CARs may be fetched in advance of handover 1577 by requesting them as part of the CARD protocol. In that case, the 1578 MN includes Trusted Anchor sub-options in the CARD request along 1579 with the L2 ID option for the AP for which the CAR certificate is 1580 desired, and the AR replies as above, except the L2 ID, address and 1581 certificates are for the CAR instead of for the AR itself. This 1582 allows the MN to skip the DCS/DCA or CARD certificate exchange when 1583 it moves to a new router. 1585 Because the amount of space in an ICMP message is limited, the 1586 router certification paths SHOULD be kept short. 1588 6.5 DoS Attack 1590 An AR can be overwhelmed with CARD Request messages. The AR SHOULD 1591 implement a rate limiting policy so that it does not send or process 1592 more than a certain number of messages per period. A suggested rate 1593 limiting policy is the following. If the number of CARD messages 1594 exceeds CARD_REQUEST_RATE, the AR SHOULD begin to randomly drop 1595 messages until the rate is reduced. MNs SHOULD avoid sending 1596 messages more frequently than CARD_REQUEST_RATE. ARs SHOULD also 1597 avoid sending unsolicited CARD Replies or CARD Requests more 1598 frequently than CARD_MIN_UPDATE_INTERVAL, but, in this case, the 1599 existence of an IPsec security association assures that messages 1600 from unknown entities will be discarded immediately during IPsec 1601 processing. 1603 MNs MUST discard CARD Replies for which there is no outstanding CARD 1604 Request, indicated by the sequence number. 1606 6.6 Replay Attacks 1607 To protect against replay attacks on the AR-AR interface, ARs SHOULD 1608 enable replay protection when negotiating the IPsec security 1609 association using IKE. 1611 On the MN-AR interface, the MN MUST discard any CARD Replies for 1612 which there is no outstanding request as determined by the sequence 1613 number. For ARs, an attacker can replay a previous request from a 1614 MN, but the attack is without serious consequence since the MN in 1615 any case ignores the reply. 1617 7. PROTOCOL CONSTANTS 1619 Constant Section Default Value Meaning 1620 -------------------------------------------------------------------- 1621 CARD_REQUEST_RETRY 5.1.1 2 seconds Wait interval before 1622 initial retransmit 1623 on MN-AR interface. 1625 CARD_RETRY_MAX 5.1.1 15 seconds Give up on retry 1626 on MN-AR interface. 1628 CARD_STARTUP_WAIT 5.2.1 1-3 seconds Maximum startup wait 1629 for an AR before 1630 performing AR-AR 1631 CARD. 1633 CARD_MIN_UPDATE_INTERVAL 5.2.1 60 seconds Minimum AR-AR update 1634 interval. 1636 CARD_REQUEST_RATE 6.5 2 requests/ Maximum number of 1637 sec. messages before 1638 AR institutes rate 1639 limiting. 1641 8. IANA CONSIDERATIONS 1643 See [Ke04] for instructions on IANA allocation. 1645 9. NORMATIVE REFERENCES 1647 [Brad97] Bradner, S., "Key words for use in RFCs to Indicate 1648 Requirement Levels", BCP 14, RFC 2119, March 1997. 1650 [Kemp02] Kempf, J., "Problem Description: Reasons For Performing 1651 Context Transfers Between Nodes in an IP Access Network", 1652 RFC 3374, September 2002. 1654 [NaNS98] Narten, T., et al., "Neighbor Discovery for IP Version 6 1655 (IPv6)", RFC 2461, December 1998. 1657 [Post80] Postel, J., "User Datagram Protocol", RFC 768, August 1980. 1659 [Stew00] Stewert, R., et. al., "Stream Control Transmission 1660 Protocol", RFC 2960, October, 2000. 1662 [AtKe98] Atkinson, R., Kent, S.,"IP Encapsulating Security Payload 1663 (ESP)", RFC 2406, November 1998. 1665 [NaAl98] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA 1666 Considerations Section in RFCs", RFC 2434, October 1998. 1668 [HarCar98] Harkins, D., and Carrel, D., "The Internet Key Exchange", 1669 RFC 2409, November, 1998. 1671 [Arkko04] Arkko, J., editor, Kempf, J., Sommerfelt, B., Zill, B., and 1672 Nikander, P., "SEcure Neighbor Discovery(SEND)", Internet 1673 draft, Work in progress. 1675 [Ke04] Kempf, J., "Instructions for Seamoby and Experimental Mobility 1676 Protocol IANA Allocations", Internet Draft, Work in progress. 1678 10. INFORMATIVE REFERENCES 1680 [TKCK02] Trossen, D., Krishanmurthi, G. Chaskar, H., Kempf, J., 1681 "Issues in candidate access router discovery for seamless 1682 IP-level handoffs", Internet Draft, Work in progress. 1684 [Kris02] Krishanmurti, G., "Requirements for CAR Discovery 1685 Protocols", Internet Draft, Work in progress. 1687 [Kenw02] Kenward, B., "General Requirements for Context 1688 Transfer", Internet Draft, Work in progress. 1690 [MaKo03] Manner, J., Kojo, M. (Ed), "Mobility Related Terminology", 1691 Internet Draft, Work in progress. 1693 [Kood03] Koodli, R, et al., "Fast handoffs for Mobile IPv6", 1694 Internet Draft, Work in progress. 1696 [Funa02] Funato, D. et al., "Geographically Adjacent Access Router 1697 Discovery Protocol", Internet Draft, Work in progress. 1699 [Tros03] Trossen, D. et al., "A Dynamic Protocol for Candidate 1700 Access-Router Discovery", Internet Draft, Work in progress. 1702 [ShGi00] Shim, E., Gitlin, R., "Fast Handoff Using Neighbor 1703 Information", Internet Draft, Work in progress. 1705 [Malk03] El Malki, K. et al., "Low Latency Handoffs in Mobile IPv4", 1706 Internet Draft, Work in progress. 1708 11. AUTHORS' ADDRESSES 1710 Hemant Chaskar 1711 Nokia Research Center 1712 5 Wayside Road 1713 Burlington, MA 01803, USA 1714 Phone: +1 781-993-3785 1715 Email: Hemant.Chaskar@nokia.com 1717 Daichi Funato 1718 NTT DoCoMo USA Labs 1719 181 Metro Drive, Suite 300 1720 San Jose, CA 95110, USA 1721 Phone: +1 408-451-4736 1722 Email: funato@docomolabs-usa.com 1724 Marco Liebsch 1725 NEC Network Laboratories 1726 Kurfuersten-Anlage 36 , 69115 Heidelberg 1727 Germany 1728 Phone: +49 6221-90511-46 1729 Email: marco.liebsch@ccrle.nec.de 1731 Eunsoo Shim 1732 NEC Laboratories America, Inc. 1733 4 Independence Way 1734 Princeton, NJ 08540, USA 1735 Phone: +1 609-951-2909 1736 Email: eunsoo@nec-labs.com 1738 Ajoy Singh 1739 Motorola Inc 1740 1501 West Shure Dr, USA 1741 Phone: +1 847-632-6941 1742 Email: asingh1@email.mot.com 1744 12. IPR STATEMENTS 1746 The IETF has been notified of intellectual property rights claimed 1747 in regard to some or all of the specification contained in this 1748 document. For more information consult the online list of claimed 1749 rights. 1751 The IETF takes no position regarding the validity or scope of any 1752 Intellectual Property Rights or other rights that might be claimed to 1753 pertain to the implementation or use of the technology described in 1754 this document or the extent to which any license under such rights 1755 might or might not be available; nor does it represent that it has 1756 made any independent effort to identify any such rights. Information 1757 on the procedures with respect to rights in RFC documents can be 1758 found in BCP 78 and BCP 79. 1760 Copies of IPR disclosures made to the IETF Secretariat and any 1761 assurances of licenses to be made available, or the result of an 1762 attempt made to obtain a general license or permission for the use of 1763 such proprietary rights by implementers or users of this 1764 specification can be obtained from the IETF on-line IPR repository at 1765 http://www.ietf.org/ipr. 1767 The IETF invites any interested party to bring to its attention any 1768 copyrights, patents or patent applications, or other proprietary 1769 rights that may cover technology that may be required to implement 1770 this standard. Please address the information to the IETF at ietf- 1771 ipr@ietf.org. 1773 13. DISCLAIMER OF VALIDITY 1775 This document and the information contained herein are provided on an 1776 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1777 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1778 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1779 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1780 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1781 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1783 14. COPYRIGHT NOTICE 1785 Copyright (C) The Internet Society (2004). This document is subject 1786 to the rights, licenses and restrictions contained in BCP 78, and 1787 except as set forth therein, the authors retain all their rights. 1789 15. CONTRIBUTORS 1791 The authors would like to thank Vijay Devarapalli (Nokia) and Henrik 1792 Petander (Helsinki University of Technology) for formally reviewing 1793 the protocol specification draft and providing valuable comments and 1794 input for technical discussions. The authors would also like to 1795 thank James Kempf for reviewing and providing lots of valuable 1796 comments and editing help. 1798 15. ACKNOWLEDGEMENTS 1800 The authors would like to thank (in alphabetical order) Dirk 1801 Trossen, Govind Krishnamurthi, James Kempf, Madjid Nakhjiri, Pete 1802 McCann, Rajeev Koodli, Robert C. Chalmers and other members of the 1803 Seamoby WG for their valuable comments on the previous versions of 1804 the document as well as for the general CARD related discussion and 1805 feedback. In addition, the authors would like to thank Erik Nordmark 1806 for providing valuable insight about the piggybacking of CARD 1807 options upon Fast Mobile IPv6 messages. 1809 APPENDIX A: MAINTENANCE OF ADDRESS MAPPING TABLES IN ACCESS ROUTERS 1811 This appendix provides information on two optional CAR table 1812 maintenance schemes for reverse address mapping in access routers. 1813 These schemes replace static configuration of the AP L2 ID to CAR IP 1814 address mapping in the CAR table. Details on these mechanisms are 1815 out of the scope of this document and intention of this appendix is 1816 to provide only a basic idea on flexible extensions to the CARD 1817 protocol as described in this document. 1819 Appendix A.1 Centralized Approach using a Server Functional Entity 1821 The centralized approach performs CARD over the MN-AR interface as 1822 described in Section 4 of this document. Additionally, the 1823 centralized approach introduces a new entity, the CARD server, to 1824 assist the current AR in performing reverse address translation. The 1825 centralized approach requires neighboring AR(s) to register with the 1826 CARD server to populate the reverse address translation table. The 1827 registration of AR addresses with the CARD server is performed prior 1828 to initiation of any reverse address translation request. 1830 Figure A.1 illustrates a typical scenario of the centralized CARD 1831 operation. In this example, ARs have registered their address 1832 information with a CARD server in advance. When a MN discovers the 1833 L2 ID of APs during L2 scanning, the MN passes one or more L2 ID(s) 1834 to its current AR and the AR resolves it to the IP address of the 1835 AR. For this, the AR first checks whether the mapping information is 1836 locally available in its CAR table. If not, the MN's current AR 1837 queries a CARD server with the L2 ID. In response, the CARD server 1838 returns the IP address of the CAR to the current AR. Then, the 1839 current AR directly contacts the respective CAR and performs 1840 capability discovery with it. The current AR then passes the IP 1841 address of the CAR and associated capabilities to the MN. The 1842 current AR then stores the resolved IP address within its local CAR 1843 table. The centralized CARD protocol operation introduces additional 1844 signaling messages, which are exchanged between the MN's current AR 1845 and the CARD server. The signaling messages between an AR and the 1846 CARD server function are shown with the preceding identifier "AR- 1847 Server", referring to the associated interface. 1849 An initial idea of performing reverse address translation using a 1850 centralized server has been described in [Funa02]. 1852 +----------+ 1853 +------------>| CARD |<-------------+ 1854 |+------------| Server |-------------+| 1855 || +----------+ || 1856 || || 1857 || ~~~~~~~~~~~ || 1858 (3)AR-Server||(4)AR-Server{ } ||(0) CARD 1859 CARD || CARD { } ||Reg Req/ 1860 Request || Reply { IP Cloud } | Reply 1861 || { } || 1862 || { } || 1863 |V ~~~~~~~~~~~ V| 1864 +---------+ (5)AR-AR CARD Request +-----+-----+ 1865 | Current |------------------------->| CAR | CAR | 1866 | AR |<-------------------------| 1 | 2 | 1867 +---------+ (6)AR-AR CARD Reply +-----+-----+ 1868 ^ | | | 1869 (2)MN-AR | |(7)MN-AR | | 1870 CARD | | CARD | | 1871 Request| V REPLY +---+ +---+ 1872 +--------------+ (1) AP1 L2 ID +--|AP1| |AP2| 1873 | Mobile |<---------------------+ +---+ +---+ 1874 | Node |<--------------------------------+ 1875 +--------------+ (1) AP2 L2 ID 1877 Figure A.1: Centralized Approach for L2-L3 mapping 1879 Appendix A.2 Decentralized Approach using Mobile Terminals' 1880 Handover 1882 This approach performs CARD over the MN-AR interface as described in 1883 Section 4. However, it employs one additional message, called the 1884 Router Identity message, over the MN-AR interface to enable ARs to 1885 learn about the reverse address translation tables of their 1886 neighboring ARs, without being dependent on any centralized server. 1888 In this approach, CAR identities in the CAR table of an AR are 1889 maintained as soft state. The entries for CARs are removed from the 1890 CAR table if not refreshed before the timeout period expires and are 1891 created or refreshed according to the following mechanism. 1893 The key idea behind the decentralized approach is to bootstrap and 1894 maintain the association between two ARs as neighbors of each other 1895 using the actual handover of MNs occurring between them as input. 1896 The first handover between any two neighboring ARs serves as the 1897 bootstrap handover to invoke the discovery procedure and the 1898 subsequent handover serves to refresh the association between the 1899 neighboring ARs. After the bootstrap handover, the MNs can perform 1900 CARD and thus seamless handover using the CAR information. This idea 1901 was presented in [ShGi00] and [Tros03]. 1903 Maintenance of the CAR table is done using an additional option for 1904 the CARD protocol operation performed between a MN and its current 1905 AR. This message serves as Router Identity message. 1907 Upon the completion of an inter-AR handover, the MN SHOULD send a 1908 Router Identity message to its current AR. This message contains the 1909 identity (IP address) of the previous AR (pAR), and can be sent as a 1910 specific sub-option in the MN-AR CARD Request message. It SHOULD be 1911 acknowledged with the MN-AR CARD Reply. The Router Identity message 1912 enables the MN's current AR to learn that the pAR (still) has an AP 1913 whose coverage overlaps with one of the APs of the current AR and 1914 vice versa. With this information, the MN's current AR can create or 1915 refresh an entry for the pAR as its neighbor. If handover is no 1916 longer possible between two ARs, the associated entries eventually 1917 timeout and are removed from each AR's CAR table. 1919 Prior to trusting the MN's report, however, the current AR may 1920 perform a number of checks to ensure the validity of the received 1921 information. One simple method is to verify the accuracy of the 1922 Router Identity message by sending an AR-AR CARD Request message to 1923 the pAR. The AR-AR CARD Request includes the identity of the MN. 1924 Upon receiving this message, the pAR verifies that the MN was indeed 1925 attached to it during a reasonable past interval and responds to the 1926 current AR. In this way, each handover of a MN results in a bi- 1927 directional discovery process between the two participating ARs. 1929 Upon receiving a positive verification response, the current AR 1930 creates or refreshes as applicable the entry for the pAR in its 1931 local CAR table. In the former case, the current AR and the pAR 1932 exchange capabilities using the AR-AR CARD Request and AR-AR CARD 1933 Reply protocol messages. When a new entry is created, the ARs MUST 1934 exchange their reverse address translation tables. They may exchange 1935 other capabilities at this time or may defer it to a later time when 1936 some MN undergoing handover between them performs CARD as described 1937 in Section 4. In the later (refresh) case, ARs may exchange 1938 capabilities or defer it until a later time when another MN 1939 undergoes handover. 1941 Finally, note that in a handover-based protocol, a first handover 1942 between a pAR and a MN's current AR cannot use CARD, as this 1943 handover bootstraps the CAR table. However, in long term, such a 1944 handover will only amount to a small fraction of total successful 1945 handover between the two AR(s). Also, if the MN engaging in such a 1946 first handover is running a non-delay sensitive application at the 1947 time of handover, the user may not even realize its impact. 1949 APPENDIX B: APPLICATION SCENARIOS 1951 This section provides two examples of an application scenario for 1952 CARD protocol operation. One scenario describes a CARD protocol 1953 operation in a Mobile IPv6 (MIPv6) network, providing access to the 1954 infrastructure via wireless LAN Access Points and associated Access 1955 Routers. A second scenario describes CARD protocol operation in a 1956 Mobile IPv6 enabled network, which has enhanced support for fast 1957 handover integrated (Fast Mobile IPv6), also providing wireless LAN 1958 access to the infrastructure. 1960 Appendix B.1 CARD Operation in a Mobile IPv6 Enabled Wireless LAN 1961 Network 1963 This application scenario assumes a moving MN having access to the 1964 infrastructure through wireless LAN (IEEE802.11) APs. Mobility 1965 management is performed using the Mobile IPv6 protocol. 1966 The following figure illustrates the assumed access network design. 1968 ----------------------------- 1969 / \ +----+ 1970 | NETWORK |---| HA | 1971 \ / +----+ 1972 ----------------------------- 1973 | | 1974 +-----+ +-----+ 1975 | AR1 |---------+ | AR2 | 1976 +-----+ | +-----+ 1977 | subnet 1 | |subnet 2 1978 +-----+ +-----+ +-----+ 1979 | AP1 | | AP2 | | AP3 | 1980 +-----+ +-----+ +-----+ 1981 ^ ^ ^ 1982 \ 1983 \ 1984 \ 1985 v 1986 +-----+ 1987 | MN | - - ->>>- - - ->>> 1988 +-----+ 1990 Figure B.1: Assumed network topology 1992 A Mobile IPv6 Home Agent (HA), maintains location information for 1993 the MN in its binding cache. From Figure B.1, the MN holds a care-of 1994 address for the subnet 1, supported by AR1. As the MN moves, the 1995 MN's current environment offers two further wireless LAN APs with 1996 increasing link-quality as candidate APs for a handover. To 1997 facilitate decision making, parameters associated with ARs are taken 1998 into account during the decision process. The AR-related parameters 1999 can be, for example, available QoS resources or the type of access 2000 technologies supported from an AR. To learn about these candidate 2001 ARs' capabilities and associated IP address information, the MN 2002 performs CARD. This requires retrieving information about candidate 2003 APs' L2 IDs Furthermore, associated link-quality parameters are 2004 retrieved to ascertain, whether or not approaching APs are eligible 2005 candidates for a handover. Assume AP2 and AP3 are suitable candidate 2006 APs. The MN encapsulates both L2 IDs (AP2 and AP3) into a CARD 2007 Request message, using the L2 ID sub-option, and sends it to its 2008 current AR (AR1). 2010 AR1 resolves each L2 ID, listed in L2 ID options to the associated 2011 IP address of the respective CAR, making use of its local CAR table. 2012 According to the environment illustrated in Figure B.1, the 2013 associated AR IP address of the candidate AP2 will be the same as 2014 the MN is currently attached to, which is AR1. Respective IP address 2015 of the candidate AR, to which AP3 is connected to, is the address of 2016 AR2. Since IP addresses of the MN's CARs are now known to AR1, AR1 2017 retrieves the CARs' capabilities from the CAR table, assumed it has 2018 valid entries for respective capability parameters To refresh 2019 dynamic capabilities, whose associated lifetime in AR1's CAR table 2020 has expired, AR1 performs Inter-AR CARD for capability discovery. 2021 Since capability information for AR1 is known to AR1, a respective 2022 Inter-AR CARD Request is sent only to AR2. AR2 in response sends a 2023 CARD Reply message back to AR1, encapsulating the requested 2024 capability parameters with the signaling message, in a Capability 2025 Container sub-option. 2026 Now, AR1 sends its own capabilities and the dynamically discovered 2027 ones of AR2 back to the MN via a CARD Reply message. Furthermore, 2028 AR1 stores the capability parameters of AR2 with the associated 2029 lifetimes in its local CAR table. 2031 On reception of the CARD Reply message, the MN performs target AR 2032 selection, taking AR1's and AR2's capability parameters as well as 2033 associated APs' link-quality parameters into account. In case the 2034 selected AP is AP2, no IP handover needs to be performed. In case 2035 AP3 and the associated AR2 are selected, the MN needs to perform an 2036 IP handover according to the Mobile IPv6 protocol operation. 2038 Figure B.2 illustrates the signaling flow of the previously 2039 described application scenario of CARD within a Mobile IPv6 enabled 2040 network. 2042 MN AP1 AR1 AP2 AP3 AR2 2043 | | | | | | 2044 | connected | | | | | 2045 0-------------0-------0 | | | 2046 | | | | | | 2047 | | | | | | 2048 | | | | 2049 | <~~~~~~~~~L2-SCAN (AP2)~~~~~| | | 2050 | <~~~~~~~~~L2-SCAN (AP3)~~~~~~~~~~~~~~~~~| | 2051 | | | | 2052 | (MN-AR) CARD Req | | | | 2053 |-------------------->| (AR-AR) CARD Req | 2054 | | |---------------------------------------->| 2055 | | | (AR-AR) CARD Repl | 2056 | (MN-AR) CARD Repl |<----------------------------------------| 2057 |<--------------------| | | | 2058 | | | | | | 2059 [target AR | | | | | 2060 selection] | | | | | 2061 | | | | | | 2062 // // // // // // 2063 [either...] | | | | | 2064 | | | | | | 2065 |-------- L2 attach --------->| | | 2066 | | | | | | 2067 | connected | | | | 2068 0---------------------0-------0 | | 2069 | | | | | | 2070 // // // // // // 2071 [... or] | | | | | 2072 | | | | | | 2073 |--------------- L2 attach -------------->| | 2074 | | | | | | 2075 | connected | | | | 2076 0-----------------------------------------0---------------------0 2077 | | | | | | 2078 | | | 2079 | MIPv6 Binding Update to the HA | | 2080 |------------------------------------------------ - - - > | 2081 | | | | | | 2083 Figure B.2: CARD protocol operation within a Mobile IPv6 enabled 2084 wireless LAN network. 2086 Appendix B.2 CARD Operation in a Fast Mobile IPv6 Network 2088 This application scenario assumes ARs can perform the fast handover 2089 protocol sequence for Mobile IPv6 [Kood03]. The MN scans for new APs 2090 for handover similar to Figure B.1 To discover the ARs (CARs), the 2091 MN attaches a MN-AR CARD Request option to the ICMP-type Fast Mobile 2092 IPv6 RtSolPr message, which is sent to the MN's current AR (pAR, 2093 previous AR). 2094 Candidate APs' L2 IDs are encapsulated using the CARD protocol's L2 2095 ID sub-options, which allow the MN to send multiple L2 IDs of 2096 candidate APs to its current AR (potentially replaces the "New 2097 Attachment Point Link-Layer Address" option of the Fast Mobile IPv6 2098 protocol). 2100 The pAR resolves the received list of candidate APs' L2 IDs to the 2101 IP address of associated CARs. The pAR checks its local CAR table to 2102 retrieve information about the CARs' capabilities. If any table 2103 entries have expired, the pAR acquires this CAR's capabilities by 2104 sending an AR-AR CARD Request to the respective CAR. The CAR replies 2105 with an AR-AR CARD Reply message, encapsulating all capabilities in 2106 a Capability Container sub-option and attaching them to the CARD 2107 Reply option. On reception of the CARs' capability information, the 2108 pAR updates its local CAR table and forwards the address and 2109 capability information to the MN of attaching a MN-AR CARD Reply 2110 option, to the Fast Mobile IPv6 PrRtAdv message. When the MN's 2111 handover is imminent, the MN selects its new AR and the associated 2112 new AP from the discovered list of CARs. According to the Fast 2113 Mobile IPv6 protocol, the MN notifies the pAR of the selected new AR 2114 with the Fast Binding Update (F-BU) message, allowing the pAR to 2115 perform a fast handover according to the Fast Mobile IPv6 protocol. 2117 Optionally, the pAR could perform selection of an appropriate new AR 2118 on behalf of the MN after the pAR has the MN's CARs' addresses and 2119 associated capabilities available. The MN must send its requirements 2120 for the selection process to its pAR together with the MN-AR CARD 2121 Request message After the pAR has selected the MN's new AR, the 2122 address and associated capabilities of the chosen new AR are sent to 2123 the MN with the CARD Reply option, in the Fast Mobile IPv6 PrRtAdv 2124 message. 2126 Figure B.3 illustrates how CARD protocol messages and functions work 2127 together with the Fast Mobile IPv6 protocol. 2129 MN pAR NAR CAR2 2130 | | as CAR1 | 2131 | | | | 2132 |-------RtSolPr------>| | | 2133 | [MN-AR CARD Req] |-- AR-AR CARD Req*->| | 2134 | |-- AR-AR CARD Req*------------>| 2135 | |<--AR-AR CARD Repl*------------| 2136 | |<--AR-AR CARD Repl*-| | 2137 |<------PrRtAdv-------| | | 2138 | [MN-AR CARD Repl] | | | 2139 | | | | 2140 NAR selection | | | 2141 |------F-BU---------->|--------HI--------->| | 2142 | |<------HACK---------| | 2143 | <--F-BACK--|--F-BACK--> | | 2144 | | | | 2145 Disconnect | | | 2146 | forward | | 2147 | packets===============>| | 2148 | | | | 2149 | | | | 2150 Connect | | | 2151 | | | | 2152 RS (with FNA option)======================>| | 2153 |<-----------RA (with NAACK option)--------| | 2154 |<=================================== deliver packets | 2155 | | | 2157 Figure B.3: Fast Handover protocol sequence with 2158 CARD protocol options 2160 *) In Figure B.3, the CARD protocol interaction between the pAR and 2161 CARs is only required in case the lifetime of any capability entries 2162 in the pAR's CAR table have expired. Otherwise, the pAR can respond 2163 to the requesting MN immediately after retrieving the CARs' address 2164 and capability information from its CAR table.