boots up to determine whether piggyback operation is possible. An
MN can also use CARD initially to determine the capabilities and
certificates for an AR on which it boots up or if it cannot obtain
the certificates beforehand. To do this, the MN includes an L2
Identifier option with its current AP L2 ID and the requested
information. The AR replies with its own information.
4.2.2. Current Access Router Operation
Upon receipt of an MN’s MN-AR CARD Request, the connected AR SHALL
resolve the requested APs’ L2 ID to the IP address of any associated
CARs. If no L2 ID parameter has been sent with the MN-AR CARD
Request message, the receiving AR retrieves all CARs’ IP addresses
and, if the C-flag was set in the request, the capability
information.
In the first case, where the AR resolves only requested L2 IDs, the
AR does not send back the L2 ID to the requesting MN. If, however,
two or more L2 IDs match the same CAR information, the L2 ID sub-
option is sent back to the MN, indicating a MATCH in the Status-Code
field of the L2 ID. Furthermore, the AR sets the Context-ID of the
returned L2 ID to the value of the resolved CAR’s L2 ID, Address, and
Capability Container sub-option. If an AR cannot resolve a
particular L2 ID, an L2 ID sub-option is sent back to the MN,
indicating a RESOLVER ERROR in the L2 ID sub-option’s Status-Code
field.
In the second case, where the AR did not receive any L2 ID with a
CARD Request, all candidate APs’ L2 IDs are sent to a requesting MN
with the CARD Reply message. The AR marks the Status-Code of
individual L2 IDs as CANDIDATE, indicating to the MN that the
associated Context-ID cannot be matched with the ID of a previously
sent request.
In any case, the AR MUST set the Context-ID of the Address and the
Capability Container sub-option to the same value as that of the
associated L2 ID sub-option.
Optionally, when allowed by local policies and supported by
respective ARs for capability discovery, the AR MAY retrieve a subset
of capabilities or CARs, satisfying the optionally appended
Preferences and Requirement message parameter, from its local CAR
table. CARs’ address information and associated capabilities are
then delivered to the MN using the MN-AR CARD Reply message. The
CARs’ IP address and the capabilities SHALL be encoded according to
the format for CARD protocol message parameters as defined in Section
5.1.3 of this document. The capabilities are encoded as attribute-
value pairs, which are encapsulated in a Capability Container message
parameter according to the format defined in Section 5.1.3.4. The
responding current AR SHALL copy the sequence number received in the
MN-AR CARD Request to the MN-AR CARD Reply.
4.3. Current Access Router - Candidate Access Router Operation
4.3.1. Current Access Router Operation
The MN’s current AR MAY initiate capability exchange with CARs either
when it receives an MN-AR CARD Request or when it detects that one or
more of its local CAR table’s capability entries’ lifetimes are about
to expire. An AR SHOULD preferentially utilize its CAR table to
fulfill requests rather than signal the CAR directly, and it SHOULD
keep the CAR table up to date for this purpose, in order to avoid
injecting unnecessary delays into the MN response.
The AR SHOULD issue an AR-AR CARD Request to the respective CARs if
complete capability information of a CAR is not available in the
current AR’s CAR table, or if such information is expired or about to
expire. The AR-AR CARD Request message format is defined in Section
5.2.2. The sequence number on the AR-AR interface starts with zero
when the AR reboots. The sending AR MUST increment the sequence
number in the CARD Request by one each time it sends a CARD Request
message.
The AR MAY append its own capabilities, which are encoded as
attribute-value pairs and encapsulated with the Capability Container
message parameter, to the released AR-AR CARD Request. If the AR-AR
CARD Request conveys the current AR’s capabilities to the CAR, the
associated Capability Container can have any value set for the
Context-ID, as there is no need for the receiving CAR to process this
field due to the absence of an L2 ID and an Address sub-option.
Furthermore, the current AR MAY set the P-flag in the Capability
Container sub-option to inform the CAR about its own capability to
perform CARD protocol message piggybacking.
Optionally, a current AR MAY append the Preferences sub-option to the
AR-AR CARD Request to obtain only capability parameters of interest
from a CAR.
Upon receipt of the AR-AR CARD Reply, sent by the CAR in response to
the previously sent request, the MN’s current AR SHALL extract the
capability information from the payload of the received message and
store the received capabilities in its local CAR table. The lifetime
of individual capabilities is to be set according to the lifetime
indicated for each capability received. The values of the table
entries’ timeouts shall depend upon the nature of individual
capabilities.
Optionally, CARs can send unsolicited CARD Reply messages to globally
adjacent ARs if the configuration of their APs or capabilities
changes dynamically. If the current AR receives an unsolicited CARD
Reply message from a CAR for which there is an entry in its local CAR
table, the current AR checks that the sequence number of the received
CARD Reply has increased compared to that of the previously received
unsolicited CARD Reply message, which has been sent from the same
CAR. Then, the current AR can update its local CAR table according
to the received capabilities. If a new CAR is added, an AR may
receive a CARD Reply from a CAR that is not in its CAR table, or from
a CAR that has rebooted. In this case, the sequence number is 0.
The requirement that ARs share an IPsec security association,
detailed in Section 6, ensures that an AR never accepts CARD
information from an unauthenticated source.
4.3.2. Candidate Access Router Operation
Upon receipt of an AR-AR CARD Request, a CAR shall extract the
sending AR’s capabilities, if the sending AR has included its
capabilities. The CAR SHALL store the received capabilities in its
CAR table and set the timer for individual capabilities
appropriately. The values of the table entries’ timeouts depend on
the nature of capabilities in the AR-AR CARD Reply message. The CAR
must include the same sequence number in the AR-AR CARD Reply Message
as that received in the AR-AR CARD Request Message. The AR-AR CARD
Reply shall include the CAR’s capabilities as list of attribute-value
pairs in the Capability Container message parameter. If the sending
AR has appended an optional Preferences sub-option, the CAR MAY
perform capability filtering and send back only those capabilities of
interest to the requesting AR, identified according to the
Preferences sub-option. Because the AR-AR CARD Reply is based on a
previously received AR-AR CARD Request, the CAR MUST set the U-flag
of the AR-AR CARD Reply to 0.
Optionally, the CAR MAY send an unsolicited CARD Reply message to
globally adjacent ARs if one or more of its capability parameters
change. Each unsolicited CARD Reply message should have as
destination address the adjacent AR’s unicast address and must have
the U-flag set. Consecutive unsolicited CARD Reply messages MUST
have the sequence number incremented accordingly, starting with 0
when the AR boots.
4.4. CARD Protocol Message Piggybacking on the MN-AR Interface
CARD supports another mode of CAR information distribution, in which
the capabilities are piggybacked on fast handover protocol messages.
To allow MNs and ARs appending the ICMP-option type CARD Request and
CARD Reply (Section 5.1.2) to the ICMP-type Fast Mobile IPv6 [Kood03]
signaling messages, the MN and AR should know about the signaling
peer’s capability for CARD protocol message piggybacking. This
requires dynamic discovery of piggybacking capability using the
P-flag in the MN-AR CARD Request and the MN-AR CARD Reply message, as
well as in the Capability Container message parameter. The format of
these messages and parameters is described in Section 5.1.
The MN sends the very first CARD Request to its current AR using the
ICMP-type CARD main header for transport, as described in Section
4.2.1. If the MN supports CARD-protocol message piggybacking, the
P-flag in this very first CARD Request message is set. On receipt of
the CARD Request message, the current AR learns about the MN’s
piggybacking capability. To indicate its piggybacking capability,
the AR sets the P-flag in the CARD Reply message. If the AR does not
support piggybacking, all subsequent CARD-protocol messages between
the MN and the AR are sent stand-alone, using the CARD main header.
If both nodes (the MN and its current AR) support CARD-protocol
message piggybacking, subsequent CARD protocol messages can be
conveyed as an option via the Fast Mobile IPv6 Router Solicitation
for Proxy (RtSolPr) and Proxy Router Advertisement (PrRtAdv)
messages. During the CARD process, an MN learns about CARs’
piggybacking capability at the discovery phase, as the Capability
Container (described in Section 5.1.3.4) also carries a P-flag. This
allows the MN to perform CARD protocol message piggybacking
immediately after a handover to a selected CAR, assuming that this
CAR supports CARD protocol piggybacking.
If a MN prefers the reverse address translation function of the Fast
Mobile IPv6 protocol, it can use CARD protocol message piggybacking
to retrieve only the CARs’ capability information. To indicate that
reverse address translation is not required, the piggybacked CARD
Request message MUST have the A-flag set. This causes the current AR
to append only Capability Container sub-options. To associate a
Capability Container sent as a parameter of the CARD Reply message to
the IP address for the appropriate CAR, the Context-ID of an
individual Capability Container MUST be used as an index, pointing to
the associated IP address in the PrRtAdv message options. The
Context-ID of individual Capability Containers is set appropriately
by the MN’s current AR. Details about how individual Context-ID
values can be associated with a particular IP address option of the
PrRtAdv message is out of the scope of this document.
5. Protocol Messages
5.1. CARD Messages for the Mobile Node-Access Router Interface
5.1.1. MN-AR Transport
The MN-AR interface uses ICMP for transport. Because ICMP messages
are limited to a single packet, and because ICMP contains no
provisions for retransmitting packets if signaling is lost, the CARD
protocol incorporates provisions for improving transport performance
on the MN-AR interface. MNs SHOULD limit the amount of information
requested in a single ICMP packet, as ICMP has no provision for
fragmentation above the IP level.
MNs and ARs use the Experimental ICMP-type main header [Ke04] when
CARD protocol messages cannot be conveyed via ICMP-type Fast Mobile
IPv6 [Kood03]. The MN-AR interface MUST implement and SHOULD use the
CARD ICMP-type header for transport. If available, the MN-AR
interface MAY use the ICMP-type Fast Mobile IPv6 [Kood03] for
transport (Section 4.4).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+- - - -
IP Fields:
Source Address:
An IP address assigned to the sending interface.
Destination Address:
An IP address assigned to the receiving interface.
Hop Limit: 255
ICMP Fields:
Type: Experimental Mobility type (assigned by IANA for
IPv4 and IPv6, see [Ke04]).
Code: 0
Checksum: The ICMP checksum.
Subtype: Experimental Mobility subtype for CARD; see [Ke04].
Reserved: This field is currently unused. It MUST be
initialized to zero by the sender and MUST be
ignored by the receiver.
Valid Options:
CARD Request: The CARD Request allows entities to request CARD-
specific information from ARs. To support
processing of the CARD Request message on the
receiver side, further sub-options may be carried,
serving as input to the reverse address translation
function and/or capability discovery function.
CARD Reply: The CARD Reply carries parameters, previously
requested with a CARD Request, back to the sender
of the CARD Request.
Valid Sub-Options:
Support level is indicated in parentheses.
Layer-2 ID (mandatory):
The Layer-2 ID sub-option [5.1.3.1] carries
information about the type of an access point as
well as the Layer-2 address of the access point
associated with the CAR whose IP address and
capability information is to be resolved.
Capability Container (mandatory):
The Capability Container sub-option carries
information about a single CAR’s capabilities. The
format of this sub-option is described in Section
5.1.3.4.
Address (mandatory):
The Address sub-option carries information on an
individual CAR’s resolved IP address. The format
of the Address sub-option is described in Section
5.1.3.5.
Trusted Anchor (mandatory):
The Trusted Anchor sub-option carries the name of a
trusted anchor for which the MN has a certificate.
The format of the Trusted Anchor sub-option is
described in Section 5.1.3.6.
Router Certificate (mandatory):
The Router Certificate sub-option carries one
certificate in the path for the current AR or for a
CAR. The chain includes certificates starting at a
trusted anchor, which the AR shares in common with
the MN, to the router itself. The format of the
Router Certificate sub-option is described in
Section 5.1.3.7.
Preferences (optional):
The Preferences sub-option carries information
about attributes of interest to the requesting
entity. Attributes are encoded according to the
AVP encoding rule, which is described in Section
5.1.4. For proper settings of AVP Code and Data
field, see Section 5.1.3.2. This sub-option is
used only if optional capability pre-filtering is
performed on ARs, and it provides only capabilities
of interest to a requesting MN.
Requirements (optional):
The Requirements sub-option carries information
about attribute-value pairs required for pre-
filtering of CARs on the MN’s current AR. This
parameter conveys MN specific attribute-value pairs
to allow the MN’s current AR to send only
information about CARs of interest back to the
requesting MN. CARs are filtered on ARs according
to the CARs’ capability parameters and given policy
or threshold, as encoded in the Requirements sub-
option. Attribute-value pairs are encoded
according to the AVP encoding rule, which is
described in Section 5.1.4. Rules for proper
setting of the AVP Code and Data field for the
Requirements sub-option are described in Section
5.1.3.3.
CARD Requests that fail to elicit a response are retransmitted. The
initial retransmission occurs after a CARD_REQUEST_RETRY wait period.
Retransmissions MUST be made with exponentially increasing wait
intervals (doubling the wait each time). CARD Requests should be
retransmitted until either a response (which might be an error) has
been obtained or CARD_RETRY_MAX seconds have occurred. ARs MUST
discard any CARD Requests having the same sequence number after
CARD_RETRY_MAX seconds. If a CARD Reply spans multiple ICMP
messages, the same sequence number MUST be used in each message.
MNs that retransmit a CARD Request use the same CARD sequence number.
This allows the AR to cache its reply to the original request and
then to send it again, should a duplicate request arrive. This
cached information should only be held for a maximum of
CARD_RETRY_MAX seconds after receipt of the request. Sequence
numbers SHOULD be chosen randomly. Random sequence numbers avoid
duplicates if MNs restart frequently and simplify sequence-number
maintenance on both the MN and AR when MNs frequently appear and
disappear due to movement between CARs.
5.1.2. CARD Options Format
All options are of the following form:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Vers.| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type: 8-bit identifier of the type of option, assigned by
IANA. See [Ke04] for CARD Request and CARD Reply
values.
Length: 8-bit unsigned integer. The length of the option,
including the type and length fields in units of 8
octets. The value 0 is invalid.
Vers.: 3-bit version code. For this specification,
Vers.=1.
5.1.2.1. CARD Request Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Vers.|P|C|A|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Fields:
Type: Assigned by IANA for IPv4 and IPv6; see [Ke04].
Length: The length of the option in units of 8 octets, including
the type and length fields as well as sub-options.
Vers.: 3-bit version code. For this specification, Vers.=1.
Flags: P-flag: Indicates the CARD-protocol message
piggybacking capability of the CARD
Request message sender. A description
for proper use of this flag can be
found in Section 4.4 of this document.
C-flag: Indicates that the requesting entity is
also interested in associated CARs’
capabilities. If the MN wants the AR
to append CARs’ capability parameters
to the CARD Reply in addition to
address information, the MN must set
this flag.
A-flag: Indicates that the requesting entity
does NOT want the receiver of this