Seamoby Working Group Dirk Trossen INTERNET DRAFT Govind Krishnamurthi 25 October 2002 Hemant Chaskar Nokia Research Center Robert C. Chalmers UC Santa Barbara Eunsoo Shim NEC Labs America A Dynamic Protocol for Candidate Access-Router Discovery draft-trossen-seamoby-dycard-00.txt Status of This Memo This document is an individual submission to the Seamoby Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the SEAMOBY@IETF.ORG mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract Many protocols currently being developed for seamless IP-level handovers, such as fast handovers and context transfers, possess an inherent requirement that the mobile node and/or it's current access router have a priori knowledge concerning the target of the handover. In particular, the target access router (TAR) should be known to have the appropriate set of capabilities necessary to meet the requirements of the mobile node. Although the TAR selection process occurs at or Trossen, et al. Expires 25 April 2003 [Page i] Internet Draft Dynamic CAR Discovery 25 October 2002 near the time of handover, applicable candidate access routers (CARs) can be identified in advance. In this draft, we propose a dynamic, distributed protocol, dyCARD, which allows geographically adjacent routers to exchange capability information, thus providing critical information to the target selection process. Trossen, et al. Expires 25 April 2003 [Page ii] Internet Draft Dynamic CAR Discovery 25 October 2002 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Terminology 2 3. Protocol Overview 3 3.1. Conceptual Data Structures . . . . . . . . . . . . . . . 3 3.2. Discovering Neighboring Routers . . . . . . . . . . . . . 3 3.3. Exchanging Capabilities . . . . . . . . . . . . . . . . . 5 3.4. Collecting Reachability Information . . . . . . . . . . . 6 3.5. TAR Selection . . . . . . . . . . . . . . . . . . . . . . 7 3.6. Security Assumptions . . . . . . . . . . . . . . . . . . 7 4. Protocol Messages 8 4.1. Router Identity Message . . . . . . . . . . . . . . . . . 8 4.2. Reachability Message . . . . . . . . . . . . . . . . . . 10 4.3. Reachability Acknowledgement Message . . . . . . . . . . 11 4.4. Candidate List Request Message . . . . . . . . . . . . . 13 4.5. Candidate List Message . . . . . . . . . . . . . . . . . 14 4.6. Geographical Neighbor Exchange Message . . . . . . . . . 16 4.7. Message Options . . . . . . . . . . . . . . . . . . . . . 18 4.7.1. Lifetime Option . . . . . . . . . . . . . . . . . 19 4.7.2. IP Option . . . . . . . . . . . . . . . . . . . . 20 4.7.3. Privacy Option . . . . . . . . . . . . . . . . . 20 4.7.4. Profile Option . . . . . . . . . . . . . . . . . 22 4.7.5. Capabilities Option . . . . . . . . . . . . . . . 23 4.7.6. Link-Layer Option . . . . . . . . . . . . . . . . 25 5. Protocol Requirements 26 5.1. Requirements for Mobile Nodes . . . . . . . . . . . . . . 26 5.2. Requirements for Access Routers . . . . . . . . . . . . . 27 6. Mobile Node Operation 27 6.1. Movement Detection . . . . . . . . . . . . . . . . . . . 27 6.2. Selecting a Source Address . . . . . . . . . . . . . . . 28 6.3. Sending Router Identity Messages . . . . . . . . . . . . 28 6.4. Tracking AP Beacons . . . . . . . . . . . . . . . . . . . 29 6.5. Sending Reachability Messages . . . . . . . . . . . . . . 29 6.6. Receiving Reachability Acknowledgement Messages . . . . . 30 6.7. Sending Candidate List Request Messages . . . . . . . . . 31 6.8. Receiving Candidate List Messages . . . . . . . . . . . . 32 Trossen, et al. Expires 25 April 2003 [Page iii] Internet Draft Dynamic CAR Discovery 25 October 2002 7. Access Router Operation 33 7.1. Receiving Router Identity Messages . . . . . . . . . . . 33 7.2. Receiving Reachability Messages . . . . . . . . . . . . . 34 7.3. Sending Reachability Acknowledgement Messages . . . . . . 35 7.4. Receiving Candidate List Request Messages . . . . . . . . 36 7.5. Sending Candidate List Messages . . . . . . . . . . . . . 37 7.6. Sending Geographical Neighbor Exchange Messages . . . . . 38 7.7. Receiving Geographical Neighbor Exchange Messages . . . . 39 8. Protocol Constants 40 9. IANA Considerations 40 10. Security Considerations 40 11. Intellectual Property Rights Notice 41 Acknowledgements 41 References 41 A. Conformance to Requirements 43 B. Optimization with Fast Mobile IPv6 47 Author Addresses 47 Trossen, et al. Expires 25 April 2003 [Page iv] Internet Draft Dynamic CAR Discovery 25 October 2002 1. Introduction Mobile IP [8, 4] enables a mobile node (MN) to execute IP-level handovers between access routers (ARs) which act as points of attachment to the IP network. However, for many scenarios, the handover latency and packet loss incurred by standard Mobile IP are too high. Thus, work is underway to develop protocols intended to provide seamless handovers (low latency and low packet loss) between ARs [3, 6, 5, 7]. Many of these seamless protocols, however, make the assumption that the MN and/or the current AR have a priori knowledge of the target of the handover, the next access router. In order to provide this information to these seamless solutions, a new protocol is required to discover geographically adjacent routers, and to collect their capabilities prior to MN handover. This document presents such a protocol, dyCARD, a dynamic candidate access-router discovery protocol. The protocol serves three key functions: 1) To provide a reverse mapping from AP layer-2 identifiers to IP addresses of supporting ARs. 2) To identify physically neighboring access routers sufficiently in advance of MN handover such that AR capabilities may be exchanged. 3) To use these collected capabilities in addition to information provided by the MN, such as reachability and preferences, to aid the MN in selecting a target access router at or near the time of handover. Three general approaches to CAR discovery exist, namely anticipated discovery, dynamic discovery and hybrid approaches. In the anticipated approach, the current AR identifies the CARs prior to handover, and subsequently selects the TAR on the behalf of the MN. Dynamic CAR selection is controlled by the MN who collects capabilities directly from reachable ARs and then performs target selection based on local policy. Hybrid approaches exists between anticipated and dynamic solutions, where both the AR and MN contribute to CAR discovery and TAR selection. In this draft, we present a hybrid approach for CAR discovery. In the protocol described herein, ARs discover neighboring CARs through the handover patterns of the mobile nodes. As a MN handsover between two adjacent ARs, the ARs learn of one another's existence, and then proceed to exchange capability information off-line over the wired backbone. After handover, a MN listens for new beacons and forwards this reachability information to the current AR. Using the previously Trossen, et al. Expires 25 April 2003 [Page 1] Internet Draft Dynamic CAR Discovery 25 October 2002 collected CAR capabilities and the MN's reachability information, the AR can then assist the MN in selecting a new target access router. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119[1]. Moreover, the following specific terms are used throughout the document: Home Address (HoA) The IPv4 or IPv6 address of the MN that it uses when it is not moving, i.e., when it is attached to its home network. Care-of Address (CoA) An IPv4 or IPv6 address configured by or assigned to the MN for use on a foreign network. Access Router (AR) A layer-3 device acting as the first-hop IP router for a mobile node. In Mobile IPv4, this would be the Foreign Agent. Access Point (AP) A layer-2 device to which a mobile node connects through a wireless link. A single AR may have many APs of differing technologies. Beacon A layer-2 message emitted by an AP, and received by a mobile node used to announce the presence of the AP. The beacon should contain some unique identifier to allow the mobile node to distinguish between APs Capabilities Information describing the services provided by a given AR. Profile The requirements and preferences of a MN as they pertain to handover. Candidate AR (CAR) An access router which is a possible target for a mobile node's handover. A CAR is a geographical neighbor of the mobile node's current AR. The two ARs have APs with overlapping coverage areas. Trossen, et al. Expires 25 April 2003 [Page 2] Internet Draft Dynamic CAR Discovery 25 October 2002 Target AR (TAR) A particular CAR chosen as the target of the mobile node's handover. Border Router A globally, IP addressable router through which a privately addressed network connects to the Internet. Disjoint Handover A handover to a new AP from which the MN could not receive beacons while attached to its previous AP. In other words, the two APs do not have overlapping coverage areas (from the view of the MN). 3. Protocol Overview 3.1. Conceptual Data Structures This document uses the conceptual data structures listed in this section to describe the operation of the CAR discovery protocol. A specific implementation does not necessarily need to implement these data structures as long as the external behavior is consistent with that described in this document. Physical Neighbor List A map of geographically adjacent ARs and their associated APs. Each AR and AP entry have independent lifetimes associated with them. Mobile Node List A list of MNs currently supported by the AR as part of the CAR discovery protocol. Each MN entry has a lifetime associated with it. Beacon Entry An entry representing a single, uniquely identifiable AP beacon. Each Beacon Entry has an associated link-layer address or other unique identifier. A locally unique 16-bit Id is assigned to each Beacon Entry by the MN. Beacon List A list of AP Beacon Entries maintained by a MN or AR which represents the current reachability of a given MN. When maintained by the MN, each Beacon Entry has an associated lifetime. 3.2. Discovering Neighboring Routers In order for an AR to be considered as a candidate for handover, the coverage area of one or more of its attached access points must overlap Trossen, et al. Expires 25 April 2003 [Page 3] Internet Draft Dynamic CAR Discovery 25 October 2002 with the coverage of the MN's existing point of attachment. Two ARs with such overlapping coverage areas are considered to be geographically adjacent, or physical neighbors. This designation differs from logically adjacent routers with only a single IP hop separating them. Geographically adjacent routers can be separated by any number of IP hops, and could actually be in completely different domains. How then do geographically adjacent routers discover each other's existence? One solution to the discovery problem would be to manually configure this list of physical neighbors for each access router. However, as previously described [10], such an approach has serious disadvantages, and in many cases, may be infeasible. For example, two ARs that are geographically adjacent may be under separate administrative control, and thus may not be informed of one another's presence. Even within the same administrative domain, manual configuration demands consistent network planning and maintenance. $ MN +----------+ +-+ +-------+ | Previous | < | | ------- | AP1 | --- | Router | ------ > +-+ +-------+ | (PAR) | < | +----------+ | IP V Network $ +----------+ +-+ +-------+ | New | < | | ------- | AP2 | --- | Router | ------ > +-+ +-------+ | (NAR) | < +----------+ Figure 1: Reference Scenario for Handovers. Therefore, we propose a dynamic approach where geographically adjacent routers are identified by the handover patterns of the mobile nodes. In short, if a MN can handover between two access points, then the associated ARs should be considered as candidates for future handovers. In this sense, it is crucial that a MN distinguish between handing-over between two adjacent APs, and simply attaching to a new access point after having disconnected from its previous AP. This requires that a MN receive beacons from new APs while still connected to its current AR/AP. Following a handover, a MN informs its new access router (NAR), as seen in Figure 1, about its previous point of attachment. In particular, the MN sends to NAR a Router Identity (RI) message (see Section 4.1) containing the IP address of the previous access router Trossen, et al. Expires 25 April 2003 [Page 4] Internet Draft Dynamic CAR Discovery 25 October 2002 (PAR), the link-layer address of the previous access point, as well as the link-layer address of the new AP. So, for the scenario depicted in Figure 1, the MN would send the tuple (PAR,AP1,AP2). With this information, NAR can create two entries in its Physical Neighbor List (PNL): 1) an entry for AP2 as a locally attached access point, and 2) an entry for PAR as a physical neighbor with the associated access point AP1. Prior to trusting the MN's report, however, NAR performs a number of checks to ensure the validity of the received information. First, AP2 must be authorized as one of NAR's local access points. This can be achieved through a managed list of APs currently attached to NAR, or by a larger set of APs that could possibly be attached over a given period of time. The size and variability of this authorization list is controlled by the ARs manager. A larger set of authorized APs provides a higher level of reconfigurability, but also increases the possibility of malicious MNs polluting the AR's PNL. To further verify the contents of the RI message, the AR sends a Geographical Neighbor Exchange (GNE) message (see Section 4.6) to the PAR. The GNE includes both the new and the previous AP identifiers, AP1 and AP2. PAR verifies that AP1 is indeed currently attached via its own local PNL entries, and that the MN was recently present. PAR replies to NAR, indicating the result of the validation. If the report was valid, PAR updates its own PNL with an entry for NAR and AP2. In this way, each handover of a MN results in a bi-directional discovery process between the two participating ARs. Further handovers simply refresh existing PNL entries. If handovers cease between two particular access routers, the associated references will eventually timeout and be removed from each AR's PNL. The dynamic nature of the CAR discovery protocol we propose adapts well to changes in the network topology. Since the PNL is maintained as soft-state in the ARs, APs that are removed will timeout. ARs that no longer overlap, will disassociate, and new APs will be discovered once a MN handsover to it. The protocol design provides for a tradeoff between the stability of the PNL and the degree of reconfigurability. Longer lifetimes applied to AP discovery via RI messages provide a more stable picture of the neighborhood in the face of few MNs. On the other hand, lower lifetimes allow APs to be moved between ARs more frequently. 3.3. Exchanging Capabilities In order to select a particular target from a list of CARs, it is necessary to learn which services each CAR can provide to the MN. This set of services, or capabilities, must be exchanged prior to actual Trossen, et al. Expires 25 April 2003 [Page 5] Internet Draft Dynamic CAR Discovery 25 October 2002 handover to ensure that the information is available at the time of TAR selection. During a validation exchange, as described in the previous section, two ARs may exchange capability information via the GNE message. Capabilities have lifetimes that are independent of, although bounded by, the PNL entries of their associated ARs. They may be refreshed during normal validation exchanges, or via explicit GNE messages. To request current capabilities, an AR simply sets the C-bit in the GNE message. The receiving AR may then return its capability set as a option in a GNE reply (see Section 4.7.5). The exact semantics of how to adequately describe capabilities are beyond the scope of this document. Actually, the CAR discovery protocol described herein can work with literally any capability representation required. The Capabilities option treats the actual data as a binary block. Marshalling, parsing and management of capability information is handled outside the CAR discovery protocol. 3.4. Collecting Reachability Information As part of the TAR selection process, the current AR can use the set of APs reachable by a MN to limit the total number of CARs considered. This has two key advantages: 1) the complexity of the TAR selection algorithm is reduced when fewer CARs are considered, and 2) less information can be transmitted to the MN in the case it controls the TAR selection process. Reachability information can be transmitted to the AR in two ways: 1) statelessly via the Candidate List Request (CLR) message (see Section 4.4), or 2) statefully via Reachability (RM) message (see Section 4.2). Using the CLR message with a list of APs, the MN can request CAR selection limited by the explicit list provided. When the RM message is used, the AR maintains state on behalf of the MN that it then uses as part of the CAR/TAR selection process. This is done statefully so that the MN can provide the information well before the time of handover, and may actually request multiple CAR selections based on the state stored at the AR; i.e., the MN may periodically refresh its current TAR selection. As a MN hears new beacons emitted by nearby APs, it reports them to its current AR via the RM message. Each beacon is reported only once upon initial reception. An acknowledgment is returned by the AR. Both the MN and the AR maintain a Beacon List which represents the MN's current reachability state. At the MN, each beacon has an associated lifetime which is dependent upon the beacon frequency. The lifetime Trossen, et al. Expires 25 April 2003 [Page 6] Internet Draft Dynamic CAR Discovery 25 October 2002 is refreshed with each received beacon. Once a beacon expires, a RM message is sent to revoke the entry in the AR's beacon list. The MN can set the S-bit in the RM message to initiate a resynchronization, providing the AR with an absolute set of Beacon Entries. This is used on the initial RM issued after handover to ensure an existing MN entry at the AR will not be reused, an example being the case where a MN moves away and then quickly back again. Moreover, if the MN detects a synchronization problem due to error conditions in the acknowledgment, it may choose to send an absolute list of current beacons to force resynchronization. The RM message may also be used to provide extra information about the MN to the AR in the form of options, such as the MN's home address or current profile. Since RM messages can be acknowledged, the MN can ensure safe reception, or subsequently retransmit on failure. 3.5. TAR Selection At any time prior to handover, a MN may request a list of CARs from the current AR via the CLR message. The AR should use the MN's current reachability state to limit the set of CARs returned. Moreover, if the AR has the MN's profile available, it could further reduce and sort the set of CARs based on the best match between the MN's requirements and the CAR capabilities. The extent of this reduction could be a property of the profile itself. Once a set of CARs has been chosen, the AR transmits this list via the Candidate List (CL) message (see Section 4.5) to the MN in the form of the AP identifiers known to the MN. In this way, the list truly consists of candidate access points. If requested by the MN, via the C-bit in the CLR, the AR may also add capability information relevant to the TAR selection process for each of the CARs. TAR selection is inherently dependent upon the semantics of the MN's profile and the AR capabilities. Again, this is beyond the scope of the CAR discovery protocol, and can be handled by a companion TAR-selection algorithm. The protocol described in this document provides the mechanism to collect and transport the appropriate information to the point of TAR selection, which could be at the current AR or the MN, but plays no part in using that information to select a target AR. 3.6. Security Assumptions In the design of this protocol, we have made a few assumptions about the security model in place between the MN and the AR, and between ARs. In particular, we assume that prior to any protocol messaging, the MN Trossen, et al. Expires 25 April 2003 [Page 7] Internet Draft Dynamic CAR Discovery 25 October 2002 and the AR have formed an appropriate security relationship. Moreover, in order for two ARs to cooperate without introducing serious security concerns, they must be able to establish a security association. For intra-domain routers, this could be as simple as a shared secret key. For the inter-domain scenario, the two domains must have a previously established relationship that can be leveraged to derive an adequate session key (e.g., AAA). All messages listed herein should be protected by IPSec to provide authentication and ensure message integrity. 4. Protocol Messages The CAR discovery protocol described in this document defines the following six messages and six options. Each message is in the form of an ICMP packet [9, 2], although other transport protocols could be used. All messages share a single ICMP type (TBA) with distinct ICMP code values. Likewise, all options share one ICMP option type (TBA) with distinct sub-types. 4.1. Router Identity Message The Router Identity (RI) message is sent by the MN to its current AR after handover. The message SHOULD be sent only after any necessary authentication has been performed and a new CoA has been configured, if necessary. If a MN is attaching to a new AR, but not handing-over directly from a previous router, then both the Previous CoA and Previous AR MUST be set to zero. This message SHOULD contain Link-Layer options with the previous and new AP identifiers, if available. If neither AP identifier is available, then the MN SHOULD NOT send this message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous CoA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous AR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Router Identity Message Format for IPv4. Trossen, et al. Expires 25 April 2003 [Page 8] Internet Draft Dynamic CAR Discovery 25 October 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Previous CoA + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Previous AR + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Router Identity Message Format for IPv6. IP Fields: Source Address The current CoA of the MN (see Section 6.2). Destination Address The address of the access router as determined from the last router advertisement of said AR. Hop Limit/TTL 1 Authentication Header If a security association exists between the MN and the AR, then the sender SHOULD include this header. ICMP Fields: Type TBA Trossen, et al. Expires 25 April 2003 [Page 9] Internet Draft Dynamic CAR Discovery 25 October 2002 Code 0 or 1. For an RI with IPv4 addresses, the code is 0; the code is 1 for RI messages containing IPv6 addresses. Checksum The ICMP checksum. RI Fields: Previous CoA The CoA used by the MN at the previous AR. Previous AR The global IP address of the previous AR. 4.2. Reachability Message The Reachability (RM) message is sent by the MN to its current AR in order to inform the AR about which APs are reachable by the MN. This message is also used to send other information about the MN to the AR, such as the MN's HoA and its current profile, as well as to periodically refresh the lifetime associated with the MN state maintained by the AR. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |A|S|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Reachability Message Format. IP Fields: Source Address The current CoA of the MN (see Section 6.2). Destination Address The address of the access router as determined from the last router advertisement of said AR. Hop Limit/TTL 1 Authentication Header If a security association exists between the MN Trossen, et al. Expires 25 April 2003 [Page 10] Internet Draft Dynamic CAR Discovery 25 October 2002 and the AR, then the sender SHOULD include this header. ICMP Fields: Type TBA Code 2 Checksum The ICMP checksum. RM Fields: Sequence Number The Sequence Number is assigned by the sender and used by the receiving node to sequence RM messages. Each RM message sent by a MN MUST use a sequence number greater than the Sequence Number value sent in any previous Reachability message, if any, to the same AR (modulo 2**16). Acknowledge (A) The Acknowledge bit is set by the sending node to request an explicit acknowledgement in response to this message. Synchronize (S) The Synchronize bit is set by the sending node to indicate that the receiving AR should remove any previous beacon state associated with the sending MN, treating the contents of the RM message as an absolute set of current reachability information. Revoke (R) The Revoke bit is set by the sender to indicate that the beacons contained within the message should be removed from the receiving AR's current Beacon List associated with the sending MN. Reserved This field is reserved for future use. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. 4.3. Reachability Acknowledgement Message The Reachability Acknowledgement (RMA) message is sent from the current AR to the MN upon reception of a RM message. IP Fields: Trossen, et al. Expires 25 April 2003 [Page 11] Internet Draft Dynamic CAR Discovery 25 October 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Reserved | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Reachability Acknowledgement Message Format. Source Address The address of the access router. This SHOULD be the Destination Address from the original RM message that this RMA is acknowledging. Destination Address The current CoA of the MN. This SHOULD be the Source Address from the original RM message that this RMA is acknowledging. Hop Limit/TTL 1 Authentication Header If a security association exists between the MN and the AR, then the sender SHOULD include this header. ICMP Fields: Type TBA Code 3 Checksum The ICMP checksum. RMA Fields: Sequence Number The Sequence Number in the RMA message is copied from the Sequence Number field in the RM message being acknowledged. Reserved This field is reserved for future use. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Trossen, et al. Expires 25 April 2003 [Page 12] Internet Draft Dynamic CAR Discovery 25 October 2002 Status An 8-bit unsigned integer indicating the status of handling the originating RM message. Values of the Status field less than 128 indicate success. The following such values are defined: 0 Success Values of the Status field greater than or equal to 128 indicate failure to process part or all of the RM message. The following such Status values are defined: 128 Bad sequence number 129 Synchronization problem 192 MN is unauthorized 193 Insufficient resources 194 Administratively prohibited 4.4. Candidate List Request Message The Candidate List Request (CLR) message is sent by the MN to its current AR to request a list of CARs or a single TAR. This message MAY contain Link-Layer and Profile options for immediate use in CAR selection. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |T|C| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Candidate List Request Message Format. IP Fields: Source Address The current CoA of the MN (see Section 6.2). Destination Address The address of the access router as determined from the last router advertisement of said AR. Hop Limit/TTL 1 Trossen, et al. Expires 25 April 2003 [Page 13] Internet Draft Dynamic CAR Discovery 25 October 2002 Authentication Header If a security association exists between the MN and the AR, then the sender SHOULD include this header. ICMP Fields: Type TBA Code 4 Checksum The ICMP checksum. CLR Fields: Sequence Number The Sequence Number is assigned by the sender and used by the receiving node to sequence CLR messages. Each CLR message sent by a MN MUST use a sequence number greater than the Sequence Number value sent in any previous Candidate List Request message, if any, to the same AR (modulo 2**16). TAR Selection (T) The TAR Selection bit is set by the sending node to request that the receiving AR attempt to perform TAR selection on behalf of the sending MN. Capabilities (C) The Capabilities bit is set by the sending node to request that the receiving AR include capabilities for the CARs returned in the associated CL message. Reserved This field is reserved for future use. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. 4.5. Candidate List Message The Candidate List (CL) message is sent by the current AR to the MN in response to a Candidate List Request. Each CAR should be represented by one or more Link-Layer options indicating the link-layer addresses of the APs associated with this AR. IP, Privacy, and Capabilities options may follow each Link-Layer option to provide extended information about each CAR (see Section 4.7). IP Fields: Trossen, et al. Expires 25 April 2003 [Page 14] Internet Draft Dynamic CAR Discovery 25 October 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |T| Reserved | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Candidate List Message Format. Source Address The address of the access router. This SHOULD be the Destination Address from the original CLR message. Destination Address The current CoA of the MN. This SHOULD be the Source Address from the original CLR message. Hop Limit/TTL 1 Authentication Header If a security association exists between the MN and the AR, then the sender SHOULD include this header. ICMP Fields: Type TBA Code 5 Checksum The ICMP checksum. CL Fields: Sequence Number The Sequence Number in the CL message is copied from the Sequence Number field in the associated Candidate List Request message. TAR Selection (T) The TAR Selection bit is set by the sending node to indicate that the sending AR performed TAR selection on behalf of the MN. Trossen, et al. Expires 25 April 2003 [Page 15] Internet Draft Dynamic CAR Discovery 25 October 2002 Reserved This field is reserved for future use. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Status An 8-bit unsigned integer indicating the status of handling the originating CLR message. Values of the Status field less than 128 indicate success. The following such values are defined: 0 Success Values of the Status field greater than or equal to 128 indicate failure to process part or all of the CLR message. The following such Status values are defined: 128 Bad sequence number 129 MN is not currently supported 130 CAR/TAR selection failed 192 MN is unauthorized 193 Insufficient resources 194 Administratively prohibited 4.6. Geographical Neighbor Exchange Message The Geographical Neighbor Exchange (GNE) message is sent from one AR to another in order to propagate topology information generated by RI messages. GNE messages are also used to exchange capabilities between ARs, as well as to periodically refresh those capabilities. A single message is used for both requests and replies since a single exchange may actually consist of more than two messages (a verification, and a two-way capability exchange). To indicate the start of an exchange, the initiating node MUST set the S-bit in the first message. Subsequent messages carry the Identifier from the initial message to indicate that they are part of the same exchange. IP Fields: Source Address The global IP address of the access router. This SHOULD be a single, global IP address that can be used by neighboring ARs to identify this router (see Section 7.6). Destination Address The global IP address of the neighboring access router. This may not be a unique address if Trossen, et al. Expires 25 April 2003 [Page 16] Internet Draft Dynamic CAR Discovery 25 October 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier |S|T|V|C| Resvd | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Geographical Neighbor Exchange Message Format. received from the Previous AR field of a RI message. Hop Limit/TTL 255 Authentication Header If a security association exists between the two ARs, then the sender SHOULD include this header. ICMP Fields: Type TBA Code 6 Checksum The ICMP checksum. GNE Fields: Identifier A unique identifier used to delineate independent message exchanges. The Identifier field should be set by the initiator of a message exchange with a value not previously used when communicating with the neighboring AR. All subsequent messages of that exchange MUST copy the Identifier field from the received message into any reply. Start (S) The Start bit is set by the sending node to indicate the start of a new message exchange. Topology (T) The Topology bit is set by the sending node to indicate that this message contains topology related options as part of the CAR discovery Trossen, et al. Expires 25 April 2003 [Page 17] Internet Draft Dynamic CAR Discovery 25 October 2002 process. This bit MUST NOT be set if the S-bit is unset; i.e., the T-bit can only be set on initial messages. Verify (V) The Verify bit is set by the sending node to indicate that a verification of the associated topology information should be performed by the receiving AR, and a reply be returned with the status of said verification. The V-bit MUST NOT be set if the T-bit is unset. Capabilities (C) The Capabilities bit is set by the sending node to request that the receiving AR provide its own capabilities as an option in the reply. Reserved This field is reserved for future use. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Status An 8-bit unsigned integer indicating the status of handling the originating GNE message. Values of the Status field less than 128 indicate success. The following such values are defined: 0 Success 1 Verified Values of the Status field greater than or equal to 128 indicate failure to process part or all of the RM message. The following such Status values are defined: 128 Local AP not verified 129 MN not verified 4.7. Message Options The CAR discovery protocol described in this document defines six new ICMP options used in conjunction with the messages defined in the previous subsections. All options share one ICMP option type (TBA) with distinct sub-types. Each option may have an Entity identifier assigned to distinguish between multiple options of the same type within the same message. The Entity associates the option with a particular participant or target of the protocol. The following entities are defined: 0 None - no entity defined Trossen, et al. Expires 25 April 2003 [Page 18] Internet Draft Dynamic CAR Discovery 25 October 2002 1 Source - the source of the message 2 Destination - the destination of the message 3 HoA - the home address of the MN 4 Previous CoA - the previous CoA of the MN 5 New CoA - the new/current CoA of the MN 6 Previous AR - the previous access router 7 New AR - the new/current access router 8 Link-Layer - an entity identified by its link-layer address Moreover, the order of options in the message are important. All options not associated with a Link-Layer entity MUST be placed in the message prior to the start of any Link-Layer options. Any option following a Link-Layer option is automatically associated with the immediately preceding Link-Layer option; the Entity MUST be set to 8, Link-Layer. New options may be added to the protocol in the future. If a receiving node does not recognize an option, it SHOULD silently ignore the option and continue processing the message. 4.7.1. Lifetime Option The Lifetime option is added to RM, RMA and GNE messages in order to request or grant a lifetime on the state maintained with regard to the message's peer. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | Entity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Lifetime Option Format Type TBA Trossen, et al. Expires 25 April 2003 [Page 19] Internet Draft Dynamic CAR Discovery 25 October 2002 Length 1 Sub-Type 0 Entity An Entity value defined in Section 4.7 indicating to which entity this option applies. Lifetime The lifetime in seconds associated with Entity. 4.7.2. IP Option The IP option is added to a message to indicate the global IP address of a given Entity. For example, an AR with a site-local or private IP address could provide the global address of a Border Router, along with a Privacy option, to be used by the MN in its RI message to the next AR. An AR may also add an IP option to a GNE exchange to provide a single, global address to be used by a peer (see Section 7.6). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | Entity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: IPv4 Option Format Type TBA Length The size of this option in units of 8 octets. Sub-Type 1 or 2. For an IPv4 option the code is 1. The code is 2 for an IPv6 option. Entity An Entity value defined in Section 4.7 indicating to which entity this option applies. IP Address The IP address of the target Entity. 4.7.3. Privacy Option The Privacy option is added to a message in order to associate a locally unique identifier with an Entity when the global IP address Trossen, et al. Expires 25 April 2003 [Page 20] Internet Draft Dynamic CAR Discovery 25 October 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | Entity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IP Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: IPv6 Option Format provided for that entity is not unique to that device; e.g. an AR with a private address which uses a global address from a Border Router. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | Entity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Privacy Option Format Type TBA Length 1 Sub-Type 3 Entity An Entity value defined in Section 4.7 indicating to which entity this option applies. Id A 32-bit unsigned identifier used to identify the target Entity when multiple nodes may share a single global IP address. Trossen, et al. Expires 25 April 2003 [Page 21] Internet Draft Dynamic CAR Discovery 25 October 2002 4.7.4. Profile Option A Profile option is added to RM messages in order to transmit a MN's current profile to an AR. The profile is treated as a binary block of data. It is not assumed that the entire profile must be sent within each option. Rather portions of or updates to the profile could be sent independently. How partial information is managed by the receiver, however, is outside the scope of this document. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | Entity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|R| Reserved | Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Profile Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Profile Option Format Type TBA Length The size of this option in units of 8 octets. Sub-Type 4 Entity An Entity value defined in Section 4.7 indicating to which entity this option applies. Absolute (A) The Absolute bit is set by the sending node to indicate that the profile data included in the option MUST override any existing profile currently cached at the receiving node with regards to the sending MN. Revoke (R) The Revoke bit is set by the sending node to indicate that the profile data included in the option MUST be removed from the receiving node's cache for the sending AR. Trossen, et al. Expires 25 April 2003 [Page 22] Internet Draft Dynamic CAR Discovery 25 October 2002 Reserved This field is reserved for future use. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Data Length The actual length in bytes of the Profile Data contained within the option. This field may be set to zero if no data is present, e.g., to revoke the complete profile. Sequence Number The Sequence Number is assigned by the sender and used by the receiving node to sequence profile updates. Each Profile option sent by a MN MUST use a sequence number greater than the Sequence Number value sent in any previous Profile option, if any, to the same receiving node (modulo 2**32). Lifetime The lifetime in seconds for the profile included in the option. Profile Data The Profile Data associated with this entity. The field MUST be zero-padded to an integral number of 8-octet units. The actual length of the data should be placed in the Data Length field. 4.7.5. Capabilities Option A Profile option is added to CL and GNE messages in order to transmit an AR's current capabilities to a MN or another AR. Capabilities are treated as a binary block of data. It is not assumed that the entire set of capabilities must be sent within each option. Rather portions of or updates to the capabilities could be sent independently. How partial information is managed by the receiver, however, is outside the scope of this document. Type TBA Length The size of this option in units of 8 octets. Sub-Type 5 Entity An Entity value defined in Section 4.7 indicating to which entity this option applies. Absolute (A) The Absolute bit is set by the sending node to indicate that the capabilities included in the option MUST override any existing capabilities Trossen, et al. Expires 25 April 2003 [Page 23] Internet Draft Dynamic CAR Discovery 25 October 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | Entity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|R| Reserved | Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capabilities Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Capabilities Option Format currently cached at the receiving node with regards to the sending AR. Revoke (R) The Revoke bit is set by the sending node to indicate that the capabilities included in the option MUST be removed from the receiving node's cache for the sending AR. Reserved This field is reserved for future use. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Data Length The actual length in bytes of the Capabilities Data contained within the option. This field may be set to zero if no data is present, i.e., to revoke the complete capabilities set. Sequence Number The Sequence Number is assigned by the sender and used by the receiving node to sequence capability updates. Each Capabilities option sent by an AR MUST use a sequence number greater than the Sequence Number value sent in any previous Capabilities option, if any, to the same receiving node (modulo 2**32). Lifetime The lifetime in seconds for the capabilities included in the option. Capabilities Data The Capabilities Data associated with this entity. The field MUST be zero-padded to an Trossen, et al. Expires 25 April 2003 [Page 24] Internet Draft Dynamic CAR Discovery 25 October 2002 integral number of 8-octet units. The actual length of the data should be placed in the Data Length field. 4.7.6. Link-Layer Option The Link-Layer option is added to messages to describe particular Entities identified by their link-layer address, namely APs. Each Link-Layer option may contain an identifier that should be sufficient to uniquely determine the Entity with respect to the context of the message. In the case that this identifier is available, the actual link-layer address may be elided to save bandwidth. Other options may be associated with a Link-Layer option to further describe properties of the Entity. Any options following a Link-Layer option, not including another Link-Layer option, are automatically associated with that Link-Layer option. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | Entity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Id | Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link-Layer Address... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: Link-Layer Option Format Type TBA Length The size of this option in units of 8 octets. Sub-Type 6 Entity An Entity value defined in Section 4.7 indicating to which entity this option applies. Id A locally unique identifier assigned by the MN to designate this link-layer address. Data Length The actual length in bytes of the Link-Layer Address contained within the option. This field Trossen, et al. Expires 25 April 2003 [Page 25] Internet Draft Dynamic CAR Discovery 25 October 2002 may be set to zero if no address is present; e.g., the Id is sufficient. Link-Layer Address The Link-Layer Address or BSSID associated with this entity. The field MUST be zero-padded to an integral number of 8-octet units. The actual length of the address should be placed in the Data Length field. 5. Protocol Requirements The protocol described in this document makes no new requirements on general IPv4 or IPv6 nodes. Only those nodes, MNs and ARs, participating in the protocol must support the features described herein. 5.1. Requirements for Mobile Nodes A mobile node participating in this CAR discovery protocol MUST fulfill the following requirements: - Every participating MN MUST support sending Router Identity messages as described in Section 6.3. - Every participating MN MUST support sending Reachability messages as described in Section 6.5. - Every participating MN MUST support receiving Reachability Acknowledgement messages as described in Section 6.6. - Every participating MN MUST support sending Candidate List Request messages as described in Section 6.7. - Every participating MN MUST support receiving Candidate List messages as described in Section 6.8. - Every participating MN MUST support detecting movement at both the link-layer and the IP-layer as described in Section 6.1. - Every participating MN SHOULD support receiving beacons from nearby APs. - Every participating MN SHOULD support a TAR resolution protocol able to incorporate profile and capability information. Trossen, et al. Expires 25 April 2003 [Page 26] Internet Draft Dynamic CAR Discovery 25 October 2002 5.2. Requirements for Access Routers An access router participating in this CAR discovery protocol MUST fulfill the following requirements: - Every participating AR MUST support receiving Router Identity messages as described in Section 7.1. - Every participating AR MUST support receiving Reachability messages as described in Section 7.2. - Every participating AR MUST support sending Reachability Acknowledgement messages as described in Section 7.3. - Every participating AR MUST support receiving Candidate List Request messages as described in Section 7.4. - Every participating AR MUST support sending Candidate List messages as described in Section 7.5. - Every participating AR MUST support sending and receiving Geographical Neighbor Exchange messages as described in Sections 7.6 and 7.7, respectively. - Every participating AR SHOULD have a single, global IP address used to identify itself with neighboring ARs, as described in Section refsec:op-ar-gne-snd. - Every participating AR SHOULD support a CAR resolution protocol able to incorporate profile and capability information. 6. Mobile Node Operation 6.1. Movement Detection The actual algorithm used to detect movement is necessarily outside the scope of this document, and dependent upon the mobility protocol employed by the MN. However, the MN MUST be aware of changes in its current attachment point, both at the link and network levels. The MN MUST be able to identify both its current AP, and its current AR. The AR SHOULD be identifiable by an address not of link-local scope. The AP can be identified by any unique identifier which we will refer to as the AP's link-layer address. Beyond detecting direct handovers between two APs, a MN SHOULD also be capable of detecting when it disconnects from it current AP/AR without handing over. This is to ensure that a MN that moves between two APs with non-overlapping coverage does not incorrectly perceive Trossen, et al. Expires 25 April 2003 [Page 27] Internet Draft Dynamic CAR Discovery 25 October 2002 the two APs as being physically adjacent. Such a ``disjoint'' change in access points could possibly be detected by the link-layer itself, or through more course grained means such as the default router entry timing out. If the MN has more than one active interface, then the previous and current AP SHOULD be tracked independently for each interface. 6.2. Selecting a Source Address A MN SHOULD maintain a consistent source address for all messages sent to a given AR. That address MUST uniquely identify the MN at the AR. In the case that the MN employs the address of the AR (e.g., a MIPv4 Foreign Agent) as its own CoA, then the MN SHOULD use its home address as the source address of its messages to the AR. 6.3. Sending Router Identity Messages Upon detecting the completion of a handover, the MN SHOULD send a RI message to its new AR according to the following rules: - In the case that the MN cannot identify either its current or previous AP, then the RI SHOULD NOT be sent. - If the MN can identify its current AP, a Link-Layer option SHOULD be added to the RI with the Entity field set to New AR. The AP's link-layer address and its length MUST be assigned to the Link-Layer Address and Data Length fields, respectively. The Id field SHOULD be set to zero. - If the handover is not disjoint, the previous and new APs have overlapping coverage areas (see Section 6.1), then the RI MUST be sent according to the following rules: * The Previous CoA field MUST be assigned the same CoA used by the MN to send RM messages to the previous AR. * The Previous AR field MUST be set to the global IP address of the previous AR. This address can be the one used directly by the MN in communication with said AR, or one supplied by the AR as an IP option. If a global IP address is not available, then the handover should be treated as disjoint. * If the previous AR provided the MN with a Privacy option, a new Privacy option MUST be added to the RI with the Id field copied from the original option sent by the AR. Trossen, et al. Expires 25 April 2003 [Page 28] Internet Draft Dynamic CAR Discovery 25 October 2002 * If the MN can identify its previous AP, a Link-Layer option SHOULD be added to the RI with the Entity field set to Previous AR. The AP identifier and its length MUST be assigned to the Link-Layer Address and Data Length fields, respectively. The Id field SHOULD be set to zero. - If the handover was disjoint then the Previous CoA and Previous AR fields MUST be set to zero. 6.4. Tracking AP Beacons Upon handover, a MN MUST clear its current Beacon List, or otherwise mark the existing beacons in the list such that the next beacon from the same AP will be treated as newly heard. When a new beacon is heard, an entry SHOULD be made in the MN's Beacon List with an appropriate lifetime. The lifetime could be a property of the beacon itself or based on the expected beacon frequency. Upon receiving subsequent beacons from the same AP, the MN SHOULD update the lifetime of associated beacon in its Beacon List. When a beacon entry's lifetime expires, it MUST be removed from the Beacon List, or otherwise marked as no longer active such that the next beacon from that AP will be treated as newly heard. 6.5. Sending Reachability Messages Reachability messages SHOULD be sent to the MN's current AR in any of the following cases: - When a new beacon is received, one not already represented in the MN's Beacon List. In this case, the link-layer address of the AP (or other unique AP identifier) MUST be included via a Link-Layer option. The locally-unique Id assigned to this beacon by the MN SHOULD be assigned to the Id field of the option. - When the lifetime of a beacon entry in the Beacon List expires. In this case, the R-bit of the RM message MUST be set. A Link-Layer option MUST be included in the message indicating which beacon. If a locally-unique Id was previously assigned to this beacon and transmitted to the AR, then only the Id SHOULD be included. - When the lifetime associated with the MN's state at the AR is close to expiration. In this case, a Lifetime option SHOULD be included in the message with the new requested lifetime. - After receiving a previous RMA message with a Status value indicating that the AR and MN are unsynchronized. In this case, Trossen, et al. Expires 25 April 2003 [Page 29] Internet Draft Dynamic CAR Discovery 25 October 2002 the S-bit of the RM message MUST be set, and a set of Link-Layer options SHOULD be included with the current contents of the MN's Beacon List. The MN MAY choose to limit the number of beacons sent in one message. In this case, beacon entries not sent MUST be deleted or mark in such a way that the next associated beacon received will trigger a new RM message as described in this subsection. Each RM message sent by the MN MUST abide by the following rules: - The first RM message sent after handover MUST have the S-bit set to indicate synchronization in case the AR has pre-existing, stale state for the MN. - The A-bit SHOULD be set for all RM messages sent. - If any beacons included in the message are to be revoked, the R-bit is set, then all beacons listed in the message MUST also be marked for revocation. In other words, a single RM message may contain beacons to add to the AR's Beacon List, or beacons to remove from th elist, but not both. - Each RM message MUST have a Sequence Number assigned larger than any previous RM message sent to the same AR, if any. Any RM sent may carry additional options such as the Profile option. Also, the MN MAY choose to delay a RM message a short time in order to collect a number of beacons in one message. If expecting an acknowledgement, the MN MAY retransmit a RM message after waiting some period of time for the associated RMA. The retransmitted message MUST have a new Sequence Number assigned larger than that of the original message. Retransmissions MUST be rate limited, and SHOULD NOT be sent more frequently than one per MIN_RM_PERIOD, and should not be repeated more than MIN_RM_RETRY times. The MN SHOULD exponentially backoff the time between each retransmission. If an acknowledgement has not been received after exhausting the total number of allowed retries, a MN SHOULD consider itself unsupported by the current AR, and cease sending further protocol messages until after handing-over to another AR. 6.6. Receiving Reachability Acknowledgement Messages Upon receiving a Reachability Acknowledgment message, the MN MUST validate the message according to the following rules: - The message MUST originate from the MN's current AR. Trossen, et al. Expires 25 April 2003 [Page 30] Internet Draft Dynamic CAR Discovery 25 October 2002 - The Sequence Number MUST match an outstanding RM message awaiting acknowledgement. An invalid RMA MUST be silently ignored. The MN MUST act on a valid RMA according to the value of the Status field: - A Success value indicates that the originating RM was accepted. The MN SHOULD update its state accordingly and MUST refrain from retransmitting the originating RM message. - For a Status value indicating that the sequence number was incorrect, the MN SHOULD increment the Sequence Number value used in the next RM by some reasonable amount. The originating RM MAY be retransmitted with this new Sequence Number. - For a Status value indicating a synchronization problem, the MN MUST transmit a new RM message with the S-bit set as described in Section 6.5. - For Status values indicating that the MN is not currently supported by the AR due to security, administrative or resource constraints, the MN SHOULD cease sending protocol message until after handing-over to another AR. 6.7. Sending Candidate List Request Messages The MN MAY send a Candidate List Request message to its current AR at any time prior to handover. The message SHOULD be sent as close to the time of handover as possible to ensure that the information provided in the associated CL message is current. The CLR message MUST be sent according to the following rules: - Each CLR message MUST have a Sequence Number assigned larger than any previous CLR message sent to the same AR, if any. - The MN MAY set the T-bit of the CLR message to request that the AR return a single TAR rather than a set of CARs. This, however, may not be supported by the current AR. - The MN MAY set the C-bit of the CLR message to request that the AR include capability information with the set of CARs returned in the CL message. - The MN MAY include Link-Layer options representing reachable AP's that should be used to select CARs. This list of APs will be used by the AR only to respond to this CLR, superceding any current beacon state maintained by the AR on behalf of the MN. Trossen, et al. Expires 25 April 2003 [Page 31] Internet Draft Dynamic CAR Discovery 25 October 2002 The previously maintained Beacon List, if any, will not be affected. - The MN MAY include a Profile option to be used by the AR in selecting appropriate CARs. This profile will be used by the AR only to respond to this message, superceding any current profile maintained by the AR on behalf of the MN. The previously maintained profile, if any, will not be affected. The MN MAY retransmit a CLR message after waiting some period of time for the associated CL message. The retransmitted message MUST have a new Sequence Number assigned larger than that of the original message. Retransmissions MUST be rate limited, and SHOULD NOT be sent more frequently than one per MIN_CLR_PERIOD, and should not be repeated more than MIN_CLR_RETRY times. If an acknowledgement has not been received after exhausting the total number of allowed retries, a MN SHOULD consider itself unsupported by the current AR and cease sending further protocol messages until after handing-over to another AR. 6.8. Receiving Candidate List Messages Upon receiving a Candidate List message, the MN MUST validate the message according to the following rules: - The message MUST originate from the MN's current AR. - The Sequence Number MUST match an outstanding CLR message awaiting acknowledgement. An invalid CL message MUST be silently ignored. The MN MUST act on a valid CL according to the value of the Status field: - A Success value indicates that the originating CLR was accepted, and that at least one CAR or TAR has been selected. The MN SHOULD pass the selected CAR(s) along to the TAR resolution algorithm, if one is available, and MUST refrain from retransmitting the originating CLR message. - For a Status value indicating that the sequence number was incorrect, the MN SHOULD increment the Sequence Number value used in the next CLR by some reasonable amount. The originating CLR MAY be retransmitted with this new Sequence Number. - For a Status value indicating that the CAR/TAR selection process failed, the MN MAY continue with sending new RM messages when appropriate. The AR MAY send new CLR messages in the future, but SHOULD NOT retransmit the originating CLR. Trossen, et al. Expires 25 April 2003 [Page 32] Internet Draft Dynamic CAR Discovery 25 October 2002 - For Status values indicating that the MN is not currently supported by the AR due to security, administrative or resource constraints, the MN SHOULD cease sending protocol message until after handing-over to another AR. 7. Access Router Operation 7.1. Receiving Router Identity Messages A MN sends a Router Identity message to its current AR after handover. The RI message carries the link-layer addresses of the previous and/or new APs, as well as the MN's previous CoA and the global address of the previous router. If the Previous AR field of the RI message is zero or set to an address local to the new AR (with the addition of a possible privacy option), then the handover is considered local to the AR. The AR MUST validate the RI message according to the following rules: - The message MUST contain either a new or previous AP address, provided via Link-Layer options with the Entity field set to New AR or Previous AR, respectively. - If the new AP address is included in the message, the AR MUST verify that the link-layer address provided in the option represents a viable local AP. This check could be made against an actual list of known attached APs, or a list of APs authorized to be considered local. - If either the Previous AR or Previous CoA fields are non-zero, both MUST be non-zero. - If the handover is local to the AR, the AR MUST further validate the message according to the following rules: * For a non-zero Previous CoA, the AR MUST verify that the MN was previously attached to the AR within a reasonable amount of time. This can be accomplished by finding an existing entry for a MN based on the Previous CoA in the AR's list of currently supported MNs. State instantiated on the MN's behalf for other protocols and services MAY also be used as a source of verification as long as the state has a reasonable lifetime associated with it. * If a previous AP address is included, the AR MUST verify that the link-layer address provided in the option represents a viable local AP. This check could be made against an actual Trossen, et al. Expires 25 April 2003 [Page 33] Internet Draft Dynamic CAR Discovery 25 October 2002 list of known attached APs, or a list of APs authorized to be considered local. An invalid RI message MUST be silently ignored. Otherwise, the AR SHOULD add any local APs referenced in the message (see above) to its Physical Neighbor List as locally attached, if not already. The AR SHOULD then update the lifetime of these AP entries to AP_LIFETIME. If the handover is not local, the AR SHOULD also create PNL entries for the neighboring AR and AP, if available. If the entries do not already exist, they SHOULD be marked as pending with a small lifetime (PENDING_LIFETIME). The AR SHOULD then send a GNE to the neighboring AR according to the rules outlined in Section 7.6. 7.2. Receiving Reachability Messages Upon receiving a Reachability message from a MN, the AR SHOULD create a new MN entry in its list of supported MNs, if not already. The AR MAY choose not to create a new entry based on administrative or resource constraints. If the AR chooses not to support the MN, it MUST return a RMA with the appropriate error value in the Status field. The rest of this subsection assumes that the AR has created the MN entry and will support the MN for CAR discovery. Upon receiving a RM message, the AR MUST verify that the Sequence Number is greater than any received from the MN in prior RM messages. This requirement only covers the current ``session'' with the MN. Once a MN handsover to another AR, the MN state MAY be deleted, and future sequence numbers do not have to be checked against those prior to deletion. If the sequence number check fails, the AR MUST return a RMA message with the appropriate error value in the Status field. For valid RM messages, the AR SHOULD update the MN's state according to the following rules: - If the A-bit is set, the AR MUST return a RMA message with an appropriate Status value. - If the S-bit is set, the AR MUST delete all existing Beacon Entries from the MN's Beacon List. - If the R-bit is set, the AR MUST delete all Beacon Entries matching those listed as Link-Layer options. A Beacon Entry MAY be identified by either the Id field or the actual Link-Layer Address if provided. If any Link-Layer option is not matched to an existing Beacon Entry, the AR MUST return a RMA with the Status field set to indicate that the AR has lost synchronization with the MN. Trossen, et al. Expires 25 April 2003 [Page 34] Internet Draft Dynamic CAR Discovery 25 October 2002 - If the R-bit is unset, the AR SHOULD create or update a Beacon Entry for each Link-Layer option included in the message. If a non-zero Id is provided, the AR MUST save this Id with the Beacon Entry. If the AR cannot handle (create or update) all of the Link-Layer options included in the message, it MUST return a RMA with the Status field set to indicate that the AR has lost synchronization with the MN. - If an IP option is included with the Entity field set to HoA, the AR MAY save the MN's HoA as part of MN entry. Whether the AR saves the HoA or not, it SHOULD set the H-bit in the RMA to inhibit the MN from continuing to send the HoA in further RM messages. - If a Lifetime option is included in the message, the AR SHOULD update the remaining lifetime of the associated MN entry by a value no greater than that specified in the Lifetime option. If the specified lifetime is zero, the AR MUST delete the MN entry immediately. The granted lifetime SHOULD be returned in the RMA as a separate Lifetime option. - If a Profile option is included in the message, the AR SHOULD save the profile data with the associated MN entry for use in CAR/TAR selection. 7.3. Sending Reachability Acknowledgement Messages The AR MUST send a Reachability Acknowledgment Message to a MN in response to a RM message if the A-bit is set or in cases where the AR cannot fulfill the requirements of processing the RM message (as described in Section 7.2. A RMA sent by the AR MUST abide by the following rules: - The Sequence Number MUST be copied from the Sequence Number field of the originating RM. - The Status field MUST be set to an error value if part or all of the RM message could not be processed. A non-error value SHOULD be used otherwise. the RM message. - If the originating RM message contained a Lifetime option, the AR SHOULD include a Lifetime option with the granted lifetime for the MN entry. The AR MAY also include an IP option with the Entity field set to Source and the IP Address field set to a global IP address that the MN should use when referring to this AR in subsequent RI messages. Trossen, et al. Expires 25 April 2003 [Page 35] Internet Draft Dynamic CAR Discovery 25 October 2002 Additionally, the AR MAY include a Privacy option with a 32-bit identifier to be used by a neighboring AR in subsequent communications. 7.4. Receiving Candidate List Request Messages If an AR receives a Candidate List Request message from a MN for which it has no corresponding MN entry, it SHOULD return a CL message indicating that the MN is not currently supported. The AR MAY choose not to fulfill the request due to administrative or resource constraints. If the AR chooses not to fulfill the CLR, it MUST return a CL message with the appropriate error value in the Status field. The rest of this subsection assumes that the AR has an associated MN entry and will support the MN for CAR discovery. Upon receiving a CLR message, the AR MUST verify that the Sequence Number is greater than any received from the MN in prior CLR messages. This requirement only covers the current ``session'' with the MN. Once a MN handsover to another AR, the MN state MAY be deleted, and future sequence numbers do not have to be checked against those prior to deletion. If the sequence number check fails, the AR MUST return a CLR message with the appropriate error value in the Status field. For a valid CLR message, the AR MUST process the message according to the following rules: - If Link-Layer options are included in the message, the AR MUST use the associated link-layer addresses as the list of reachable APs for use in CAR/TAR selection. Otherwise, the AR MUST use the Beacon Entries from the Beacon List associated with the MN, if any. - If a Profile option is included in the message, the AR MUST use the associated profile data for use in CAR/TAR selection. Otherwise, the AR MUST use the profile stored in association with the MN, if any. - The AR SHOULD select a limited number of CARs based on a number of factors. The exact selection algorithm is beyond the scope of this document. * Only those CARs SHOULD be considered that have associated AP entries in the PNL which match the list of reachable AP reported by the MN. * Pending entries, those not yet validated via a GNE exchange, SHOULD NOT be considered. Trossen, et al. Expires 25 April 2003 [Page 36] Internet Draft Dynamic CAR Discovery 25 October 2002 * The MN's profile, if available, SHOULD be used in conjunction with the neighboring AR capabilities to select the most appropriate CARs. The total number of CARs returned to the MN could be a parameter of the MN's profile. * If the T-bit is set in the CLR message, the AR MAY select a single CAR as a target AR. - If the C-bit is set in the CLR message, the AR SHOULD attempt to return capability information for each CAR in the selected list. The capabilities sent MAY be a subset of the complete AR capabilities, dependent upon the MN's profile. Again, how to reduce the capability sets is dependent upon the format and content of the capabilities and profile, and are beyond the scope of this document. 7.5. Sending Candidate List Messages An AR MUST send a Candidate List message in response to a CLR message from a supported MN. A MN is considered supported if the AR maintains state on behalf of the MN as a result of previous RM messages. If the MN is unsupported and the CLR message does not contain an explicit list of reachable APs, the AR SHOULD return a CL message with an appropriate Status value indicating the lack of MN state at the AR. A CL sent by the AR MUST abide by the following rules: - The Sequence Number MUST be copied from the Sequence Number field of the originating CLR. - The T-bit MUST be set if a single TAR was selected. This differs from the case where only one CAR was available, but was not necessarily selected as a TAR. - The Status field MUST be set to an error value if part or all of the CLR message could not be processed. A non-error value SHOULD be used otherwise. - Each selected CAR SHOULD be represented by one or more Link-Layer options indicating the associated APs selected as targets for the MN handover. Extra information associated with each AP, such as related IP addresses or capabilities, MUST follow the Link-Layer option as separate options prior to the next Link-Layer option in the message. Trossen, et al. Expires 25 April 2003 [Page 37] Internet Draft Dynamic CAR Discovery 25 October 2002 7.6. Sending Geographical Neighbor Exchange Messages Each AR SHOULD have a global ``identifying'' IP address that it uses in communication with neighboring routers. This is necessary since a single router may have multiple assigned addresses, each interface with a different address. As the MN moves between routers, it will see only the interface-specific address of the router. Thus, a single AR would look like multiple neighbors to another AR that receives RIs from MNs handing-over from each of the different interfaces. The identifying address is used to unify the PNL entries for a neighboring AR. All Geographical Neighbor Exchange messages sent to a neighboring AR SHOULD use this identifying address as the Source Address. One exception is noted below. An AR MAY send a GNE message to a neighboring router in any of the following situations: - The AR receives a valid RI message with a previous AP address specified as a Link-Layer option with the Entity field set to Previous AR. In this case, the S and T-bits MUST be set. The V-bit SHOULD be set unless the AR does not require verification of the previous AP for some unspecified reason. If present, the new AP and/or previous AP Link-Layer options included in the RI SHOULD be copied to the GNE. - The AR attempts to verify the previous AP address of a GNE sent by a neighboring router, and the V-bit is set in the originating GNE. The Status field MUST be set to Verified if verification succeeds, or an appropriate error value otherwise. If the Destination Address of the originating GNE is not the identifying address of the AR, the Source Address of the reply GNE MUST be set to the Destination Address of the initial GNE; an IP option SHOULD be added to the message with the Entity field set to Source and the IP Address field assigned the identifying address. - The AR receives a GNE from a neighboring router with the C-bit set. The AR MUST verify that the sending AR is a valid neighboring AR by checking for a non-pending entry in the PNL. The return GNE SHOULD contain a Capabilities option with the AR's capability information. - The AR requires the capabilities of a neighboring router, or the existing set of capabilities are close to expiration. In this case, the AR MUST set the C-bit of the GNE. For initial packets of a message stream, those with the S-bit set, the AR MUST select an Identifier with a good chance of remaining unique between the two communicating ARs for the duration of the exchange. For subsequent packets, the Identifier field MUST be copied from Trossen, et al. Expires 25 April 2003 [Page 38] Internet Draft Dynamic CAR Discovery 25 October 2002 the originating GNE message. The S, T and V-bits MUST NOT be set in non-initial packets. 7.7. Receiving Geographical Neighbor Exchange Messages Upon receiving a Geographical Neighbor Exchange message, the AR MUST validate the message according to the following rules: - If the S-bit is not set, the T and V-bits MUST NOT be set. - If the T-bit is set, the previous AP address MUST be included as a Link-Layer option with the Entity field set to Previous AR. - If the T-bit is set, the AR MUST verify that the previous AP's link-layer address provided in the option represents a viable local AP. This check could be made against an actual list of known attached APs, or a list of APs authorized to be considered local. The AR MUST silently discard invalid GNE messages. For valid GNE messages, processing is dependent upon the value of the S-bit. If the S-bit is set, the following rules MUST be followed in processing the GNE: - If the T-bit is set, the AR SHOULD create a PNL entry for the previous AP as locally attached, if not already. The AR SHOULD update the lifetime of the previous AP entry to AP_LIFETIME. - If the T-bit is set, the AR SHOULD create a PNL entry for the neighboring AR in its PNL, if not already. The AR SHOULD mark this entry as non-pending. If the new AP is included in the GNE message, the AR SHOULD create an associated AP entry related to the neighboring AR in the PNL, if not already. The AR SHOULD update the lifetime of the new AP entry to AP_LIFETIME. - If a Lifetime option is included in the GNE, the AR SHOULD update the lifetime of the corresponding neighbor entry in the PNL, if it exists, with a value no greater than that specified in the option. The granted lifetime SHOULD be returned in a GNE reply message. If the S-bit is not set, the following rules MUST be followed in processing the GNE: - If an IP option is included with the Entity field set to Source, the address indicated by the option SHOULD be used by the AR as the identifying address of the neighboring router. An existing PNL entry for the Source Address of the message SHOULD Trossen, et al. Expires 25 April 2003 [Page 39] Internet Draft Dynamic CAR Discovery 25 October 2002 be converted to or merged with a PNL entry for the identifying address. 8. Protocol Constants The description of the CAR discovery protocol introduces a number of constants that we further define in this section. Each of these values MUST be configurable. MIN_RM_PERIOD 2 sec. MAX_RM_RETRY 5 MIN_CLR_PERIOD 0.5 sec. MAX_CLR_RETRY 3 AP_LIFETIME 180 sec AR_LIFETIME 600 sec. PENDING_LIFETIME 30 sec. 9. IANA Considerations The messages described herein require a single ICMP type to be assigned from the available type space. Message code values should be standardized, but do not require assignment from an existing, restricted numbering space. Likewise, the options described in this document require the assignment of a single ICMP option type, and sub-types should be standardized. If some options could be reused in other protocols, it may be useful to define unique types for those options. 10. Security Considerations In order to secure both the discovery process, as well as the capability and profile exchanges, all messages should be secured with IPSec to provide authentication and ensure message integrity. The primary question is whether the security associations between the MN and AR and between neighboring ARs explicitly provide any type of authorization to engage in the CAR discovery protocol. If not, then a separate facility is necessary to provide this type of authorization, e.g., ACLs. Even with authorized security associations, the discovery process is not completely secure since the ARs depend upon the MNs to properly Trossen, et al. Expires 25 April 2003 [Page 40] Internet Draft Dynamic CAR Discovery 25 October 2002 report their handovers. Although a number of verification steps, outlined in Sections 7.1 and 7.7, provide strong evidence that a given RI message is valid, it is possible for a malicious MN to pollute the PNL of ARs. However, since all PNL entries are maintained as soft-state, the MN or a collection of MNs would need to continually provide false information to sustain the polluted entries. Moreover, the polluted entries would not affect non-malicious MNs since CAR selection is based on the reachability information provided by the non-malicious MN. If the attack was persistent and widespread, though, it could possibly result in resource exhaustion at the AR. The AR SHOULD limit the size of the PNL to eliminate this possibility. 11. Intellectual Property Rights Notice Nokia Corporation and/or its affiliates hereby declare that they are in conformity with Section 10 of RFC 2026. Nokia's contributions may contain one or more patents or patent applications. To the extent Nokia's contribution is adopted to the specification, Nokia undertakes to license patents technically necessary to implement the specification on fair, reasonable and nondiscriminatory terms based on reciprocity. Acknowledgements The authors would like to acknowledge Richard D. Gitlin for his efforts in the design of this protocol. References [1] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [2] A. Conta and S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. Request for Comments (Draft Standard) 2463, Internet Engineering Task Force, December 1998. [3] K. El Malki (Editor). Low Latency Handoffs in Mobile IPv4. Technical Report draft-ietf-mobileip-lowlatency-handoffs-v4-*.txt, Internet Engineering Task Force (IETF), June 2002. [4] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6. Technical Report draft-ietf-mobileip-ipv6-*.txt, Internet Engineering Task Force (IETF), June 2002. Trossen, et al. Expires 25 April 2003 [Page 41] Internet Draft Dynamic CAR Discovery 25 October 2002 [5] J. Kempf (Editor). Problem Description: Reasons for Performing Context Transfers between Nodes in an IP Access Network. Request for Comments (Informational) 3374, Internet Engineering Task Force (IETF), September 2002. [6] R. Koodli (Editor). Fast Handovers for Mobile IPv6. Technical Report draft-ietf-mobileip-fast-mipv6-*.txt, Internet Engineering Task Force (IETF), July 2002. [7] G. Krishnamurthi, Chalmers R., and C. Perkins. Buffer Management for Smooth Handovers in Mobile IPv6. Technical Report draft-krishnamuthi-mobileip-buffer6-*.txt, Internet Engineering Task Force (IETF), March 2001. [8] C. Perkins. IP Mobility Support. Request for Comments (Proposed Standard) 2002, Internet Engineering Task Force, October 1996. [9] J. Postel. Internet Control Message Protocol. Request for Comments (Standard) 792, Internet Engineering Task Force, September 1981. [10] D. Trossen, G. Krishnamurthi, H. Chaskar, and J. Kempf. Issues in Candidate Access Router Discovery. Technical Report draft-ietf-seamoby-cardiscovery-*.txt, Internet Engineering Task Force (IETF), November 2001. Trossen, et al. Expires 25 April 2003 [Page 42] Internet Draft Dynamic CAR Discovery 25 October 2002 A. Conformance to Requirements Identifying the IP Address of a CAR The mapping between the link-layer address of an AP, as known to the MN, and the IP address of the associated AR is achieved as part of the dynamic topology discovery process. When the MN sends an RI message to its new AR, it specifies both the IP address of the previous AR, as well as the link-layer identifier of the previous AP. This allows ARs to build the AP to AR mapping. This mapping can then be provided, if necessary, to the MN as an IP option associated with each Link-Layer option in a CL message returned to the MN. Support for Inter-Technology Handoffs Since the Link-Layer option format does not dictate any particular length or form for the AP identifiers, dyCARD is independent of the actual technologies used at the link-level. The only assumption made by the protocol is that two APs of differing technology with overlapping coverage areas would not have identifiers that are of the same length and the same value. In this case, they would be viewed as a single AP by the ARs. Identifying CARs having Site-local and Private Addresses Site-local and private addresses are accommodated by the protocol through the use of IP and privacy options. If an AR does have a private address on the interface accessed by the MN, the AR informs the MN of which global IP address and private Id to use when sending an RI to the next AR. This global address/private Id pair is then used by the new AR to contact the previous AR given that the device owning the global address, such as a Border Router, participates in the exchange. Exactly how this should be accomplished is beyond the scope of this document. Capability Discovery ARs are able to exchange and refresh capabilities once a neighboring relationship has been established. The GNE message can be used to request new capabilities. The actual capabilities are carried in the Capabilities option. Capabilities can also be forwarded to the MN through the same option, as part of the CL message. Trossen, et al. Expires 25 April 2003 [Page 43] Internet Draft Dynamic CAR Discovery 25 October 2002 Utilization of Network Resources The CAR discovery protocol we have proposed makes every effort to limit the bandwidth used, especially over the wireless link between the MN and the AR. Specifically, the semi-stateful design of the reachability message limits the number of messages to at most two per distinct beacon received, one upon first receiving the beacon and possibly another if the beacon disappears. Moreover, each RM message can contain multiple beacon reports. The use of beacon Ids also works towards reducing bandwidth. Upon reporting a new beacon, the MN assigns it a locally unique Id which it sends in the Link-Layer option. Later, when the AR sends a CL message with a list of candidate APs, only the Ids need be present, the actual addresses may be elided. The same applies to revoking a previously reported beacon. Another design feature intended to save bandwidth on the wireless link is the use of the Beacon List by the AR to reduce the set of possible CARs sent to the MN. Capabilities sent along with each CAR could also be reduced to include only those items relevant to the MN's requirements. Finally, the CLR message includes the T-bit which when set allows the AR to perform the TAR selection procedure locally and return only the selected TAR. Format of Capabilities The correct operation of the CAR discovery protocol is not dependent upon the format of capabilities or the MN profile. All messages exchange capabilities and profiles as binary blocks. The management and use of these blocks of data are delegated to companion specifications related to the TAR selection algorithm, and are outside the scope of this document. Scope of CAR Discovery The design of the CAR discovery protocol is in no way restricted by the location of the two neighboring ARs. They could be within the same domain, or in different domains administered separately. The only requirement made by the protocol is that the two ARs are capable of establishing a security association that provides the explicit authorization to engage in the CAR discovery protocol. Trossen, et al. Expires 25 April 2003 [Page 44] Internet Draft Dynamic CAR Discovery 25 October 2002 Introduction of Dedicated Network Elements for CAR Discovery The CAR discovery protocol described in this document does not introduce any new network elements. The only exception is the necessary presence of some proxy device that would allow the use of a global address/private Id pair to establish communication with a privately addressed AR. This, however, is not a new requirement for supporting private address spaces. Involvement of Non-CARs in CAR Discovery Only the MN and the two ARs involved in a particular handover participate in the CAR discovery protocol. Dependence on a Mobility Management Protocol The CAR discovery protocol does not depend on any particular mobility protocol in order to operate correctly. Within this document, we use terminology, such as Care-of Address, that is normally related specifically to Mobile IP. This, however, is done only to simplify the discussion. In the presence of other mobility-related protocols, there are opportunities for optimizing the performance of our protocol. See Appendix B for details on optimizing performance when used in conjunction with Fast Mobile IPv6. Effect of Changes in Network Topology The dynamic nature of the CAR discovery protocol we propose adapts well to changes in the network topology. Since the PNL is maintained as soft-state in the ARs, APs that are removed will timeout. ARs that no longer overlap, will disassociate, and new APs will be discovered once a MN handsover to it. The protocol design provides for a tradeoff between the stability of the PNL and the degree of reconfigurability. Longer lifetimes applied to AP discovery via RI messages provide a more stable picture of the neighborhood in the face of few MNs. On the other hand, lower lifetimes allow APs to be moved between ARs more frequently. Providing the MN's Requirements to the CAR Discovery Solution The MN may provide its current AR with a list of its requirements for CAR selection in the form of a Profile option included in any RM message sent by the MN. The AR can then take advantage of the MN's profile to Trossen, et al. Expires 25 April 2003 [Page 45] Internet Draft Dynamic CAR Discovery 25 October 2002 better select a set of viable CARs, and possibly reduce the amount of capability information required to send back to the MN. Secure Capability Transfer All protocol messages should be protected by IPSec to provide authentication and ensure message integrity. The capability data may also be encrypted and/or digitally signed to further ensure secure transportation. Verification of Router Authenticity Verification of a neighboring AR's authenticity is approached in two ways. First, the two ARs must establish a security association via some means outside the scope of the CAR discovery protocol. This security association should provide an explicit authorization to engage in exchanging topological information. Secondly, neighboring ARs are initially discovered through the handover pattern of MNs. In order for two ARs to have discovered one another, a MN must have moved between their respective APs. Moreover, the AP identifiers provided by the MN are verified at both the new and previous ARs in order to filter out faulty information provided by a malicious MN. However, in the case that an incorrect PNL entry is instantiated, the result is simply a temporary allocation of memory in the AR. MN handovers will not be affected since only ARs matching the reachability information provided by the MN are selected as CARs. Secure Inter-Operability with IETF Protocols The CAR discovery protocol described in this document employs IPSec for securing communication between all parties, between two ARs and between an AR and a MN. The packet formats described in Section 4 use ICMP, although this is not a necessary constraint. The protocol does not create any new threats to the use of existing protocols. Secure Expression of MN's Requirements to the CAR Discovery Solution All protocol messages should be protected by IPSec to provide authentication and ensure message integrity. The profile data may also be encrypted and/or digitally signed to further ensure secure transportation. Trossen, et al. Expires 25 April 2003 [Page 46] Internet Draft Dynamic CAR Discovery 25 October 2002 B. Optimization with Fast Mobile IPv6 In the presence of other mobility-enabling protocols, such as Fast Mobile IPv6 [6], it is possible to optimize the message flow of the CAR discovery protocol described by this document. In particular, the CLR and CL messages could be overlaid onto the Proxy Router Solicitation and Proxy Router Advertisement messages, respectively. This would require a slight change to Fast MIPv6 in order to allow advertisements from multiple ARs in the Proxy Router Advertisement. New options would also be required to carry the AR capabilities and AP identifiers. Employing this type of optimization would eliminate one round-trip between the MN and the AR near the time of handover. This is quite desirable since link quality may fade significantly as a MN reaches the edge of a given APs coverage area. Moreover, the MN would receive the most current CAR list available since the transaction would occur immediately before handover. Author Addresses Questions about this memo can be directed to the authors: Dirk Trossen Communications Systems Laboratory Nokia Research Center 5 Bayside Road Burlington, MA 01803 USA +1 781 993 3605 +1 781 993 1907 (fax) dirk.trossen@nokia.com Govind Krishnamurthi Communications Systems Laboratory Nokia Research Center 5 Bayside Road Burlington, MA 01803 USA +1 781 993 3627 +1 781 993 1907 (fax) govind.krishnamurthi@nokia.com Hemant Chaskar Communications Systems Laboratory Nokia Research Center 5 Bayside Road Trossen, et al. Expires 25 April 2003 [Page 47] Internet Draft Dynamic CAR Discovery 25 October 2002 Burlington, MA 01803 USA +1 781 993 3785 +1 781 993 1907 (fax) hemant.chaskar@nokia.com Robert C. Chalmers Department of Computer Science University of California, Santa Barbara Santa Barbara, CA 93106 USA +1 805 893 7520 +1 805 893 8553 (fax) robertc@cs.ucsb.edu Eunsoo Shim NEC Labs America 4 Independence Way Princeton, NJ, 08540 USA eunsoo@nec-lab.com Trossen, et al. Expires 25 April 2003 [Page 48]