Request for Comments: 4066 A. Singh, Ed.
Category: Experimental H. Chaskar
D. Funato
E. Shim
July 2005
Candidate Access Router Discovery (CARD)
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
To enable seamless IP-layer handover of a mobile node (MN) from one
access router (AR) to another, the MN is required to discover the
identities and capabilities of candidate ARs (CARs) for handover
prior to the initiation of the handover. The act of discovery of
CARs has two aspects: identifying the IP addresses of the CARs and
finding their capabilities. This process is called "candidate access
router discovery" (CARD). At the time of IP-layer handover, the CAR,
whose capabilities are a good match to the preferences of the MN, is
chosen as the target AR for handover. The protocol described in this
document allows a mobile node to perform CARD.
Table of Contents
1. Introduction.................................................. 2
2. Terminology................................................... 3
3. CARD Protocol Functions....................................... 4
3.1. Reverse Address Translation............................. 4
3.2. Discovery of CAR Capabilities........................... 4
4. CARD Protocol Operation....................................... 4
4.1. Conceptual Data Structures.............................. 7
4.2. Mobile Node - Access Router Operation................... 8
4.3. Current Access Router - Candidate Access Router
Operation............................................... 11
4.4. CARD Protocol Message Piggybacking on the MN-AR
Interface............................................... 13
5. Protocol Messages............................................. 14
5.1. CARD Messages for the Mobile Node-Access Router
Interface............................................... 14
5.2. CARD Inter-Access Router Messages....................... 28
6. Security Considerations....................................... 31
6.1. Veracity of CARD Information............................ 31
6.2. Security Association between AR and AR.................. 31
6.3. Security Association between AR and MN.................. 32
6.4. Router Certificate Exchange............................. 32
6.5. DoS Attack.............................................. 34
6.6. Replay Attacks.......................................... 34
7. Protocol Constants............................................ 34
8. IANA Considerations........................................... 35
9. Normative References.......................................... 35
10. Informative References........................................ 35
11. Contributors.................................................. 36
12. Acknowledgements.............................................. 36
Appendix A. Maintenance of Address Mapping Tables in
Access Routers....................................... 37
Appendix A.1. Centralized Approach Using a Server Functional
Entity.......................................... 37
Appendix A.2. Decentralized Approach Using Mobile Terminals’
Handover........................................ 38
Appendix B. Application Scenarios................................ 40
Appendix B.1. CARD Operation in a Mobile IPv6-Enabled Wireless
LAN Network..................................... 40
Appendix B.2. CARD Operation in a Fast Mobile IPv6-Enabled
Network......................................... 43
1. Introduction
IP mobility protocols, such as Mobile IP, enable mobile nodes to
execute IP-level handover among access routers. Work is underway
[Kood03][Malk03] to extend the mobility protocols to allow seamless
IP handover. Seamless IP mobility protocols will require knowledge
of candidate access routers (CARs) to which a mobile node can be
transferred. The CAR discovery protocol enables the acquisition of
information about the access routers that are candidates for the
mobile node’s next handover.
CAR discovery involves identifying a CAR’s IP address and the
capabilities that the mobile node might use for a handover decision.
There are cases in which a mobile node has a choice of CARs. The
mobile node chooses one according to a match between the mobile
node’s requirements for a handover candidate and the CAR’s
capabilities. However, the decision algorithm itself is out of the
scope of this document.
The problem statement for CAR discovery is documented in [TKCK02].
In this document, a protocol is described to perform CAR discovery.
Section 3 describes two main functions of the CAR discovery protocol.
Section 4 describes the core part of the CARD protocol operation.
The protocol message format is described in Section 5. Section 6
discusses security considerations, and Section 7 contains a table of
protocol parameters. Appendix A contains two alternative techniques
for dynamically constructing the CAR table mapping between the access
point L2 ID and Access Router IP address, which is necessary for
reverse address translation. The default method is static
configuration. Appendix B contains two sample scenarios for using
CARD.
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 [Brad97].
This document uses terminology defined in [MaKo03].
In addition, the following terms are used:
Access Router (AR)
An IP router residing in an access network and connected to one or
more APs. An AR offers IP connectivity to MNs.
Candidate AR (CAR)
An AR to which an MN has a choice when performing IP-level
handover.
Capability of an AR
A characteristic of the service offered by an AR that may be of
interest to an MN when the AR is being considered as a handover
candidate.
L2 ID
An identifier of an AP that uniquely identifies that AP. For
example, in 802.11, this could be a MAC address of an AP.
CARD Initiating Trigger
An L2 trigger used to initiate the CARD process. For example, a
MN can initiate CARD as soon as it detects the L2 ID of a new AP
during link layer scan.
Access Point (AP)
A wireless access point, identified by a MAC address, providing
service to the wired network for wireless nodes.
3. CARD Protocol Functions
The CARD protocol accomplishes the following functions.
3.1. Reverse Address Translation
If an MN can listen to the L2 IDs of new APs prior to making a
decision about IP-level handover to CARs, a mechanism is needed for
reverse address translation. This function of the CARD protocol
enables the MN to map the received L2 ID of an AP to the IP address
of the associated CAR that connects to the AP. To get the CAR’s IP
address, the MN sends the L2 ID of the AP to the current AR, and the
current AR provides the associated CAR’s IP address to the MN.
3.2. Discovery of CAR Capabilities
Information about the capabilities of CARs can assist the MN in
making optimal handover decisions. This capability information
serves as input to the target AR selection algorithm. Some of the
capability parameters of CARs can be static, whereas others can
change with time.
A definition of capabilities is out of the scope of this document.
Encoding rules for capabilities and the format of a capability
container for capability transport are specified in Section 5.
4. CARD Protocol Operation
The CARD protocol allows MNs to resolve the L2 ID of one or more APs
to the IP addresses of the associated CARs. The L2 IDs are typically
discovered during an operation by the MN and are potential handover
candidates. Additionally, CARD allows MNs to discover particular
capabilities associated with the CARs, such as available bandwidth,
that might influence the handover decision of the MN. Furthermore,
the protocol allows ARs to populate and maintain their local CAR
table (Section 4.1) with the capabilities of CARs. For this, the
CARD protocol makes use of CARD Request and CARD Reply messages
between an MN and its current AR (Section 5.1.2), and between an MN’s
current AR and individual CARs, respectively (Section 5.2.2).
To allow an MN to retrieve a CAR’s address and capability
information, the CARD Request and CARD Reply messages used between an
MN and its current AR may contain one or more access points’ L2 IDs
and the IP addresses of associated CARs, respectively. Optionally,
the CARD Reply messages can also contain a CAR’s capability
information. A CAR’s capabilities are specified as a list of
attribute-value pairs, which are conveyed in a Capability Container
message parameter.
Information about CARs and associated capabilities MAY be used by the
MN to perform target access router selection during its IP handover.
The current AR returns replies according to its CAR table (see
Section 4.1) and returns a RESOLVER ERROR (see Section 5.1.3.1) if
the request cannot be resolved.
The CARD protocol also enables an MN to optionally indicate its
preferences on capabilities of interest to its current AR by
including the Preferences message parameter in the CARD Request
message. The MN’s current AR MAY use this information to perform
optional capability pre-filtering for optimization purposes, and it
returns only these capabilities of interest to the requesting MN.
The format of this optional Preferences message parameter is
described in Section 5.1.3.2.
Optionally, the MN can provide its current AR with a list of
capability attribute-value pairs, indicating not only the capability
parameters (attributes) required for capability pre-filtering, but
also a specific value for a particular capability. This allows the
MN’s current AR to perform CAR pre-filtering and to send only address
and capability information of CARs whose capability values meet the
requirements of the MN back to the requesting MN. The format of this
optional Requirements message parameter is described in Section
5.1.3.3.
For example, using the optional Preferences message parameter, an MN
may indicate to its current AR that it is interested only in
IEEE802.11a interface-specific capability parameters, as this is the
only interface the MN has implemented. The MN’s current AR sends
back only CARs with IEEE802.11a-specific capabilities. Similarly,
using the optional Requirements message parameter, an MN may indicate
to its current AR that it is only interested in CARs that can satisfy
a given QoS constraint. Here, an MN sends the respective QoS
attribute with the QoS constraint value to its current AR using the
optional Requirements message parameter. The QoS constraint is
denoted as an attribute-value pair and encapsulated with the
Requirements message parameter, which is appended to the MN-
originated CARD Request message. The Requirements message parameter
may be used to indicate the cutoff values of the capabilities for any
desired CARs. According to the received optional list of attributes
in the Preferences parameter or a list of attribute-value pairs in
the Requirements message parameter, the MN’s current AR MAY use these
parameters for deciding the content of the solicited CARD Reply
message, which is to be sent back to the MN. Alternatively, if the
MN’s current AR does not perform optimization with regard to
capability or CAR pre-filtering, the current AR MAY choose to
silently ignore the optional Requirements and Preferences message
parameter as received in the CARD Request message.
The MN can additionally request from the AR a certification path that
is anchored at a certificate from a shared, trusted anchor. The MN
includes in the CARD Request message a list of trusted anchors for
which the MN has a certificate, and the AR replies with the
certification path. If no match is found, the AR returns the trusted
anchor names from the CARD Request. The MN can ask for a chain for
either the current AR or a CAR. If the trusted anchor list is
accompanied by an AP L2 ID for the MN’s current AP, the returned
chain is for the current AR. If the L2 ID is for an AP that the MN
has heard during scanning and is not connected to the current AR, the
returned chain is for a CAR. The chain is returned as a sequence of
CARD Reply messages, each message containing a single certificate,
the L2 identifier for the AP sent in the CARD Request, and a router
address for the CAR (or for the AR itself if a request was made for
the AR). When the chain is complete, the MN can use it to obtain the
AR’s certified key and thereby validate signatures on CARD messages
and other messages between the MN and the current AR. The MN only
has to send the trusted anchor option if it does not have the
certification path for the AR already cached. If the MN has the
certification path cached, through preconfiguration, through previous
receipt of the chain from this router, or by having received the
chain through a previous router, then the trusted anchor does not
have to be sent. More information about certificate exchange and its
use in CARD security can be found in Section 6.
The CARD protocol operation, as described in this section,
distinguishes signaling messages exchanged between an MN and its
current AR from those exchanged between ARs. Hence, descriptions of
signaling messages in the following sections have preceding
identifiers referring to the associated interface. Messages that are
exchanged between an MN and AR are designated as "MN-AR", and
messages between ARs are designated as "AR-AR".
+--------------+ (1a)AR-AR CARD Request +----------+
| Current |------------------------->| CAR |
| AR |<-------------------------| |
+--------------+ (2a)AR-AR CARD Reply +----------+
^ |
| | MN-AR
MN-AR | | CARD Reply(3m)
CARD Request(2m) V
+--------------+
| Mobile |
| Node |<-- CARD Init Trigger
+--------------+ (1m)
Figure 1: MN-initiated CARD Protocol Overview
Figure 1 describes the operation of the MN-AR CARD Request/Reply
protocol and AR-AR CARD Request/Reply protocol. On receipt of the
access points’ L2 IDs or the appearance of a CARD initiation trigger
(1m), the MN may pass on one or more AP L2 IDs to its current AR
using the MN-AR CARD Request message (2m). If the MN wants its AR to
perform capability discovery in addition to reverse address
translation, this must be indicated in the MN-AR CARD Request message
by setting the C-flag. If the C-flag is not set, the AR receiving
the CARD Request message will perform only reverse address
translation. The MN’s current AR resolves the L2 ID to the IP
address of the associated CAR or, if the MN has not attached any L2
ID message parameters, just reads out all CARs’ IP address
information using the reverse address translation information (L2 ID
to IP address mapping) from its local CAR table. The current AR then
returns to the MN using the MN-AR CARD Reply message (3m), the IP
addresses of any CARs, each CAR’s set of L2 IDs with CANDIDATE
indicated in the L2 ID sub-option status field, and, if capability
information has been requested, associated capabilities.
For the AR-AR CARD Request/Reply protocol, the requesting AR sends a
CARD Request message to its peer when the CAR table entries time out
(1a). The peer returns a CARD Reply message with the requested
information (2a).
4.1. Conceptual Data Structures
ARs SHALL maintain an L2-L3 address mapping table (CAR table) that is
used to resolve L2 IDs of candidate APs to the IP address of the
associated CAR. By default, this address-mapping table is configured
statically for the CARD protocol operation. Optionally, the CAR
table MAY be populated dynamically. Two possible approaches are
described in Appendices A.1 and A.2.
ARs SHOULD also keep and maintain individual CARs’ capabilities in
the local CAR table, with the associated capability lifetime taken
into account. If the lifetime of an individual capability entry has
expired, the respective capability information is updated. An AR may
also initiate capability exchange prior to expiration of the
capabilities associated with a CAR in the CAR table, thereby
populating its CAR table. The AR’s CAR table may be implemented
differently; therefore additional details are not provided here. ARs
MUST maintain their own AP-to-AR mappings and capability information
in their CAR tables, in order to provide newly booted MNs with this
information so that an MN can obtain the AR’s certification path.
MNs SHOULD maintain discovered address and capability information of
CARs in a local cache to avoid requesting the same information
repeatedly and to select an appropriate target AR from the list of
CARs as quickly as possible when a handover is imminent.
4.2. Mobile Node - Access Router Operation
4.2.1. Mobile Node Operation
To initiate CARD, an MN sends a CARD Request to its current AR,
requesting it to resolve the L2 ID of nearby access points to the IP
address of associated CARs and also obtain capability parameters
associated with these CARs. If the requesting MN wants its current
AR to resolve specific L2 IDs, the MN-AR CARD Request MUST contain
the CARD protocol-specific L2 ID message parameters. If the MN wants
its AR to perform only reverse address translation without appending
the CARs’ capabilities, the MN refrains from setting the C-flag in
the CARD Request message. If the MN wants to perform capability
discovery, the MN MUST set the C-flag in the CARD Request message.
The CARD Request MAY also contain the Preferences or Requirements
message parameter, indicating the MN’s preferences on capability
attributes of interest or its requirements on CARs’ capability
attribute-value pairs.
If the MN appends multiple L2 ID sub-options to a CARD Request, the
AR MUST assume that each L2 ID is associated with an AP that connects
to a different CAR. Since L2 IDs, address information, and
capability information are transmitted with separate sub-options,
each sub-option carries a Context-ID, to allow parameters that belong
together to be matched. Therefore, the MN MUST assign different
Context-ID values to the L2 ID sub-options it appends to the CARD
Request message. The Status-Code field of the L2 ID sub-option MUST
always be set to NONE (0x00) by the MN. The MN MUST set the sequence
number to a randomly generated value, and the AR MUST include the
sequence number in all messages of the reply. If the reply spans
multiple messages, each message contains the same sequence number.
Upon receipt of the corresponding MN-AR CARD Reply message, the MN
correlates the CARD Reply with the appropriate CARD Request message
and then processes all MN-AR CARD Reply message parameters to
retrieve its CAR’s address and capability information. If the MN is
unable to correlate the CARD Reply with any previously sent CARD
Request messages, the MN SHOULD silently discard the reply. This may
happen when the MN reboots after sending a CARD Request message to
the connected AR.
An MN uses exponential backoff to retransmit the CARD Request in the
event that a CARD Reply is not received within CARD_REQUEST_RETRY
seconds. The retransmitted CARD Request MUST have the same sequence
number as the original. With the exception of certification paths,
which are large by nature, an AR SHOULD attempt to limit the
information in a CARD Reply to a single message. Should that be
impossible, the AR MAY send the reply in multiple messages. The last
message of a reply MUST always have the L-flag set in the CARD Reply
option to indicate that the message is the last for the associated
sequence number. An AR retransmitting replies to a CARD Request MUST
always send the full CARD Reply sequence. The Trusted Anchor sub-
option and the Router Certificate sub-option provide a means whereby
the MN can request specific certificates in a certification path, in
the event that the CARD Reply carrying a certification path spans
multiple messages and one of them is lost. However, a request for
specific certificates that were not received in the initial CARD
Reply MUST be treated as a new request by the MN and MUST use a
different sequence number.
Processing the Context-ID of Address sub-options allows the MN to
assign the resolved IP address of a specific CAR to an L2 ID.
In some cases, an L2 ID parameter is present in a CARD Reply message.
The Status-Code field in the L2 ID parameter indicates one of the
following reasons for its being sent toward the MN.
RESOLVER ERROR Status-Code indication:
If the MN’s current AR could not resolve a particular L2 ID, this
status code is returned to the MN.
MATCH Status-Code indication:
If an L2 ID is encountered that shares a CAR with a previously
resolved L2 ID, the AR returns MATCH to the MN. This status code
indicates that the Context-ID of this particular L2 ID sub-option
has been set to the Context-ID of the associated CAR’s Address and
Capability Container sub-option, which is sent with this CARD
Reply message. This approach avoids sending the same CAR’s
address and capability information multiple times with the same
CARD Reply message in case two or more L2 IDs resolve to the same
CAR. An MN uses the Context-ID received in the L2 ID sub-option
as the key to find the serving CAR of the given AP from the
content of the received CARD Reply message.
CANDIDATE Status-Code indication:
If the MN does not append any L2 ID to the CARD Request, the AR
sends back the L2 ID and address information of all CARs. Because
the received parameters’ Context-IDs cannot be correlated with an
L2 ID’s Context-ID of a previously sent request, the AR chooses
values for the Context-ID and marks these candidate L2 IDs with
CANDIDATE in the status code of the distributed L2 IDs. However,
individual values of L2 IDs’ Context-ID allow the MN to assign a
particular L2 ID to the associated Address and the possibly
received Capability Container sub-option.
As described in Section 4.5, an MN can use CARD when it initially