RFC 4066
Candidate Access Router Discovery (CARD)
Part 1 of 11 🎀
Candidate Access Router Discovery (CARD) 🦋
okay bestie, this is RFC 4066 and it's giving mobility protocol main character energy ✨
- Network Working Group 🌸
- Request for Comments: 4066
- Authors: M. Liebsch, Ed.; A. Singh, Ed.; H. Chaskar; D. Funato; E. Shim (the "Ed." means they're the editors 💅)
- Category: Experimental 🧪
- Date: July 2005 📅
- Obsoletes / Updates: nothing listed in the title block. It doesn't obsolete or update any other document 🙈
Status of This Memo
ngl this section is so important. This memo defines an Experimental Protocol for the Internet community, and 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
okay so the big idea 🔥 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 before the handover even starts. Discovery of CARs has two parts: figuring out the IP addresses of the CARs, and finding out what they can do. This whole process is called "candidate access router discovery" (CARD) 🫶
When it's time for the IP-layer handover, the CAR whose capabilities best match the MN's preferences gets picked as the target AR 👑 The protocol in this document lets a mobile node do 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......................................... 431. Introduction ✨
okay so IP mobility protocols, like Mobile IP, let mobile nodes do IP-level handover among access routers 🦋 There's work going on [Kood03][Malk03] to extend the mobility protocols so handover can be seamless. Seamless IP mobility protocols will need to know about the candidate access routers (CARs) that a mobile node could be moved to. The CAR discovery protocol gets info about the access routers that are candidates for the mobile node's next handover 💅
CAR discovery is about figuring out a CAR's IP address, plus the capabilities the mobile node might use when it decides on a handover 🔥 Sometimes a mobile node has a choice of CARs. It picks one by matching its own requirements for a handover candidate against each CAR's capabilities. The decision algorithm itself is out of scope for this document 🙈
The problem statement for CAR discovery is written up in [TKCK02]. This document describes a protocol that does CAR discovery 🎀 Section 3 covers the two main functions of the CAR discovery protocol. Section 4 covers the core of the CARD protocol operation. The protocol message format is in Section 5. Section 6 talks about security considerations, and Section 7 has a table of protocol parameters. Appendix A has two alternative techniques for dynamically building the CAR table that maps the access point L2 ID to the Access Router IP address, which reverse address translation needs. The default method is static configuration. Appendix B has 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].
okay and these extra terms are used too 👑
Access Router (AR) 🌸
An IP router in an access network that's connected to one or more APs. An AR gives IP connectivity to MNs.
Candidate AR (CAR) ✨
An AR that an MN gets to choose from when it's doing an IP-level handover.
Capability of an AR 💅
A feature of the service an AR offers that an MN might care about when it's considering that AR as a handover candidate.
L2 ID 🦋
An identifier for an AP that uniquely identifies that AP. For example, in 802.11, this could be an AP's MAC address.
CARD Initiating Trigger 🔥
An L2 trigger used to kick off the CARD process. For example, an MN can start CARD as soon as it detects the L2 ID of a new AP during a link layer scan 🧚
Access Point (AP) 🍓
A wireless access point, identified by a MAC address, that provides service to the wired network for wireless nodes.
3. CARD Protocol Functions 🎀
The CARD protocol does the following functions.
3.1. Reverse Address Translation 🌷
okay so if an MN can hear the L2 IDs of new APs before it decides on an IP-level handover to CARs, it needs a mechanism for reverse address translation 🙈 This CARD function lets the MN map the L2 ID of a received AP to the IP address of the associated CAR that connects to that AP. To get the CAR's IP address, the MN sends the AP's L2 ID to its current AR, and the current AR gives the MN the associated CAR's IP address 💜
3.2. Discovery of CAR Capabilities 💫
Info about CAR capabilities can help the MN make the best handover decisions 🏆 This capability info is the input to the target AR selection algorithm. Some capability parameters of CARs can be static, while others can change over time ✨
Defining capabilities is out of scope for this document. The encoding rules for capabilities and the format of a capability container for capability transport are specified in Section 5. 🎀
4. CARD Protocol Operation ✨
Okay bestie, so CARD is the protocol that lets an MN (mobile node) resolve the L2 ID of one or more APs into the IP addresses of the associated CARs 🧚. The L2 IDs usually get discovered by the MN during an operation, and they're the potential handover candidates 💖. CARD also lets MNs find out about particular CAR capabilities, like available bandwidth, which can totally influence the MN's handover decision 👑. And ARs can fill up and maintain their local CAR table (Section 4.1) with CAR capabilities 🎀. To make all this happen, CARD uses 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 (Section 5.2.2), respectively 💅.
To let an MN grab a CAR's address and capability info, the CARD Request and CARD Reply messages between the MN and its current AR can carry one or more access points' L2 IDs and the IP addresses of associated CARs, respectively 🦋. The CARD Reply can optionally include a CAR's capability info too ✨. Those capabilities are a list of attribute-value pairs, carried in a Capability Container message parameter 🌸.
Information about CARs and their capabilities MAY be used by the MN to pick a target access router during its IP handover 🫶. The current AR replies based on its CAR table (see Section 4.1). If it can't resolve the request, it sends back a RESOLVER ERROR (see Section 5.1.3.1) 😭.
The CARD protocol also lets an MN optionally say which capabilities it's into by including the Preferences message parameter in the CARD Request 💜. The MN's current AR MAY use this info to do optional capability pre-filtering for optimization purposes, and then it returns only the capabilities of interest to the requesting MN 🔥. The format of this optional Preferences parameter is in Section 5.1.3.2.
Optionally, the MN can give its current AR a list of capability attribute-value pairs. These say not only which capability parameters (attributes) matter for pre-filtering, but also a specific value for a particular capability ✨. That lets the current AR pre-filter CARs and send back only the address and capability info of CARs whose capability values meet the MN's requirements 👑. The format of this optional Requirements parameter is in Section 5.1.3.3.
For example, with the optional Preferences parameter, an MN can tell its current AR it's only interested in IEEE802.11a interface-specific capability parameters, since that's the only interface the MN has implemented 🎀. The current AR sends back only CARs with IEEE802.11a-specific capabilities 💅. Similarly, with the optional Requirements parameter, an MN can say it's only interested in CARs that can satisfy a given QoS constraint 🌈. Here, the MN sends the respective QoS attribute with the constraint value to its current AR in the optional Requirements parameter, which is appended to the MN-originated CARD Request. The Requirements parameter may be used to indicate the cutoff values of the capabilities for any desired CARs. Based on the attribute list in Preferences, or the attribute-value pairs in Requirements, the MN's current AR MAY use these parameters to decide what goes into the solicited CARD Reply sent back to the MN 💖. Alternatively, if the MN's current AR doesn't do capability or CAR pre-filtering, the current AR MAY choose to silently ignore the optional Requirements and Preferences parameters received in the CARD Request 🙈.
The MN can also ask for a certification path anchored at a certificate from a shared, trusted anchor 🧚. It includes a list of trusted anchors it has a certificate for in the CARD Request, 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 comes with 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 the MN heard during scanning and isn't connected to through the current AR, the returned chain is for a CAR 👑. The chain comes back as a sequence of CARD Reply messages. Each message has 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 the request was for the AR) 🫶. Once the chain is complete, the MN can use it to get the AR's certified key and 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 doesn't already have the AR's certification path cached. If it does have the path cached, whether through preconfiguration, through previous receipt of the chain from this router, or by having received the chain through a previous router, the trusted anchor doesn't have to be sent 🌸. More info about certificate exchange and its role in CARD security is in Section 6 🎀.
The CARD operation described in this section separates signaling messages exchanged between an MN and its current AR from those exchanged between ARs 🦋. So the descriptions of signaling messages in the following sections have preceding identifiers that refer to the associated interface. Messages exchanged between an MN and an AR are designated "MN-AR", and messages between ARs are designated "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 OverviewFigure 1 shows the operation of the MN-AR CARD Request/Reply protocol and the AR-AR CARD Request/Reply protocol 🍓. On receipt of the access points' L2 IDs, or when a CARD initiation trigger (1m) shows up, the MN may pass 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 do capability discovery in addition to reverse address translation, it has to say so in the MN-AR CARD Request by setting the C-flag. If the C-flag isn't set, the AR receiving the CARD Request only does reverse address translation 🫶. The MN's current AR resolves the L2 ID to the IP address of the associated CAR. Or, if the MN hasn't attached any L2 ID message parameters, the AR just reads out all CARs' IP address info from its local CAR table, using the reverse address translation info (the L2 ID to IP address mapping) 🎀. The current AR then returns, in the MN-AR CARD Reply message (3m), the IP addresses of any CARs, each CAR's set of L2 IDs with CANDIDATE in the L2 ID sub-option status field, and, if capability info was requested, the associated capabilities 💜.
For the AR-AR CARD Request/Reply protocol, the requesting AR sends a CARD Request message to its peer when its CAR table entries time out (1a) 😭. The peer returns a CARD Reply message with the requested info (2a) 🦋.
4.1. Conceptual Data Structures 🌈
ARs SHALL maintain an L2-L3 address mapping table (the CAR table) that's 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 CARD 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 info is updated 💖. An AR may also initiate capability exchange before the capabilities associated with a CAR in the CAR table expire, which populates its CAR table 🦋. The AR's CAR table may be implemented differently, so additional details aren't provided here 🫶. ARs MUST maintain their own AP-to-AR mappings and capability info in their CAR tables, so they can give newly booted MNs this info, and the MN can then obtain the AR's certification path 👑.
MNs SHOULD maintain discovered address and capability info of CARs in a local cache 🎀. That avoids requesting the same info repeatedly, and lets the MN 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 ✨
okay so bestie, to kick things off, an MN sends a CARD Request to its current AR 💌 asking it to resolve the L2 IDs of nearby access points into the IP addresses of the CARs they're linked to, and to grab the capability parameters for those CARs too 🦋. If the MN wants its AR to resolve specific L2 IDs, the MN-AR CARD Request MUST contain the CARD protocol-specific L2 ID message parameters. If the MN only wants reverse address translation and doesn't want the CARs' capabilities tagged along, it just doesn't set the C-flag in the CARD Request. If the MN wants capability discovery, the MN MUST set the C-flag in the CARD Request message. The CARD Request MAY also carry the Preferences or Requirements message parameter, which is how the MN says which capability attributes it's curious about 👀 or what its must-haves are for the CARs' capability attribute-value pairs.
If the MN tacks multiple L2 ID sub-options onto one CARD Request, the AR MUST assume that each L2 ID is tied to an AP that connects to a different CAR 🧩. Since L2 IDs, address info, and capability info all travel in separate sub-options, every sub-option carries a Context-ID so the parameters that belong together can be matched up. So 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.
Once the matching MN-AR CARD Reply lands, the MN correlates it with the right CARD Request, then processes all the MN-AR CARD Reply message parameters to pull out its CAR's address and capability info ✨. If the MN can't correlate a CARD Reply with any CARD Request it sent before, the MN SHOULD silently discard the reply 🙈. That can happen when the MN reboots after sending a CARD Request to the connected AR.
If no CARD Reply shows up within CARD_REQUEST_RETRY seconds, the MN retransmits the CARD Request using exponential backoff 📈. The retransmitted CARD Request MUST have the same sequence number as the original. Except for certification paths (which are large by nature 📜), an AR SHOULD try to keep a CARD Reply to a single message. If that's 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, so the MN knows it's the final one for that 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 give the MN a way to ask for specific certificates in a certification path, in case the CARD Reply carrying that path spans multiple messages and one of them gets lost 💔. However, a request for specific certificates that weren't 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 lets the MN assign the resolved IP address of a specific CAR to an L2 ID 🎀.
Sometimes an L2 ID parameter shows up in a CARD Reply. The Status-Code field in that L2 ID parameter tells you which of these reasons it was sent to the MN:
RESOLVER ERRORStatus-Code indication: If the MN's current AR could not resolve a particular L2 ID, this status code is returned to the MN.MATCHStatus-Code indication: If an L2 ID is encountered that shares a CAR with a previously resolved L2 ID, the AR returnsMATCHto the MN. This status code means theContext-IDof this particular L2 ID sub-option has been set to theContext-IDof the associated CAR's Address and Capability Container sub-option, which is sent with this CARD Reply message. This avoids sending the same CAR's address and capability information multiple times in one CARD Reply, in case two or more L2 IDs resolve to the same CAR 💅. An MN uses theContext-IDreceived 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.CANDIDATEStatus-Code indication: If the MN doesn't 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 can't be correlated with an L2 ID'sContext-IDfrom a previously sent request, the AR chooses values for theContext-IDand marks these candidate L2 IDs withCANDIDATEin the status code of the distributed L2 IDs. Still, individual values of the L2 IDs'Context-IDlet the MN 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 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 it boots up on, or if it can't 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 IDs to the IP addresses 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 the L2 ID back 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 AR-AR CARD Request being sent out. 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 ✨
okay so when a CAR gets an AR-AR CARD Request, it shall pull out the sending AR's capabilities, but only if that AR actually included them 🫶. The CAR SHALL stash those capabilities in its CAR table and set the timers for each individual capability appropriately 💅. The timeout values for those table entries depend on what kind of capabilities show up in the AR-AR CARD Reply message 🌸. The CAR must copy the same sequence number into the AR-AR CARD Reply Message that it got in the AR-AR CARD Request Message, no skipping 🎀. The AR-AR CARD Reply shall pack the CAR's capabilities as a list of attribute-value pairs inside the Capability Container message parameter 🧚. If the sending AR tacked on an optional Preferences sub-option, the CAR MAY do capability filtering and only send back the capabilities of interest to the requesting AR, as identified by that Preferences sub-option 👑. Since the AR-AR CARD Reply is a response to a request it already received, the CAR MUST set the U-flag of the AR-AR CARD Reply to 0 🔥.
Optionally (no pressure 💖), 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 should have the adjacent AR's unicast address as its destination address, and it must have the U-flag set. Consecutive unsolicited CARD Reply messages MUST have their sequence number incremented accordingly, starting with 0 when the AR boots ⭐.
4.4. CARD Protocol Message Piggybacking on the MN-AR Interface
CARD has another trick up its sleeve 🦋: CAR info can also be distributed by piggybacking the capabilities onto fast handover protocol messages. So MNs and ARs can tack the ICMP-option type CARD Request and CARD Reply (Section 5.1.2) onto ICMP-type Fast Mobile IPv6 [Kood03] signaling messages, the MN and AR should know whether the signaling peer has the capability for CARD protocol message piggybacking 🌈. That needs dynamic discovery of the piggybacking capability, using the P-flag in the MN-AR CARD Request and the MN-AR CARD Reply message, plus the one in the Capability Container message parameter 💅. The formats of these messages and parameters are 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. When the current AR receives the CARD Request message, it learns about the MN's piggybacking capability. To indicate its own 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, because the Capability Container (described in Section 5.1.3.4) also carries a P-flag. This lets the MN do CARD protocol message piggybacking right after a handover to a selected CAR, assuming that this CAR supports CARD protocol piggybacking 🎀.
If an 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 with 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 current AR sets the Context-ID of individual Capability Containers appropriately. Details about how individual Context-ID values can be associated with a particular IP address option of the PrRtAdv message are 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. ICMP messages are limited to a single packet, and ICMP has no way to retransmit packets if signaling is lost, so the CARD protocol includes provisions for improving transport performance on the MN-AR interface 💖. MNs SHOULD limit the amount of information requested in a single ICMP packet, since ICMP has no provision for fragmentation above the IP level.
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 get a response are retransmitted. The initial retransmission happens 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 passed. 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 lets the AR cache its reply to the original request and then send it again, should a duplicate request arrive. This cached information should only be held for a maximum of 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 they simplify sequence-number maintenance on both the MN and AR when MNs keep appearing and disappearing because they move between CARs 🌈.
5.1.2. CARD Options Format
okay so every CARD option has the exact same shape, bestie, which is honestly so iconic of it. 🎀 Type, then Length, then a 3-bit version field, then the stuff that's unique to each option. Here's the layout:
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.| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field does 💅:
Type: an 8-bit option type. IANA assigns these, and [Ke04] has the CARD Request and CARD Reply values.Length: an 8-bit unsigned integer. It's the length of the option in units of 8 octets, counting the type and length fields too. A value of0is invalid, so don't even 🙅♀️.Vers.: a 3-bit version code. In this spec,Vers.=1.
5.1.2.1. CARD Request Option
this is the one the MN uses to ask for stuff, and it's giving very specific vibes 🔥
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, the tea ☕:
Type: assigned by IANA for IPv4 and IPv6. See [Ke04].Length: the length of the option in units of 8 octets. This includes the type and length fields as well as the sub-options.Vers.: a 3-bit version code. In this spec,Vers.=1.
The Vers. field is followed by a bunch of flags, and each one has its own personality ✨
- P-flag: tells you whether the sender can do CARD-protocol message piggybacking. For how to use it properly, check Section 4.4 of this document.
- C-flag: says the requester also cares about the associated CARs' capabilities. If the MN wants the AR to tack the CARs' capability parameters onto the CARD Reply, alongside the address info, the MN must set this flag 🫶.
- A-flag: says the requester does NOT want the receiver to do reverse address translation. This flag gets set when CARD protocol messages are piggybacked on a protocol that does reverse address translation. For the details, see Section 4.4 of this document.
- T-flag: says the requester wants every certificate the responder has. This flag only works on the AR-AR interface, so it's a no-go elsewhere.
The flag combo A=1 and C=0 is invalid, and T=1 is invalid on the MN-AR interface. The AR MUST discard an invalid message and log an appropriate error message. Not optional, bestie 💀
Then there's the rest of the header:
Reserved: set to zero when you send it, and ignored when you receive it.Sequence Number: this is how requests get matched up with their replies 🧚.
The valid sub-options for this one are:
- L2 ID sub-option
- Preferences sub-option
- Requirements sub-option
- Trusted Anchor sub-option
Now for the boundary alignment drama 😭. To make sure the 64-bit boundary requirements are met, each sub-option MUST meet its own 64-bit boundary alignment requirement. If they all do, the whole CARD Request option lines up on the 8n alignment constraint. Main character energy for memory layout 👑.
5.1.2.2. CARD Reply Option
and this is the reply side of things, which is basically the AR giving the MN its answer 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Vers.|P|U|L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -Fields:
Type: assigned by IANA for IPv4 and IPv6 [Ke04].Length: the length of the option in units of 8 octets, including the type and length fields as well as sub-options.Vers.: a 3-bit version code. In this spec,Vers.=1.
Flags, round two 🌈:
- P-flag: tells you whether the sender of the CARD Reply can piggyback CARD-protocol messages. For proper use, see Section 4.4 of this document.
- U-flag: marks an unsolicited CARD Reply. This one only counts on the AR-AR interface.
- L-flag: gets set if this message is the last one in a multiple ICMP message reply. It's only valid on the MN-AR interface.
The flag U=1 on an AR-MN message is invalid. An invalid message should be discarded and an appropriate error message logged. Wild that it's the same vibe as the request side but spicier 💅
Reserved: set to zero on send, ignored on receipt.Sequence Number: same job as before, matching requests to replies 💖.
Valid sub-options:
- L2 ID sub-option
- Capability Container sub-option
- Address sub-option
- Router Certificate sub-option
And the alignment rule again, because it matters 🙈. Each sub-option MUST meet the 64-bit boundary alignment requirements individually. That keeps the whole CARD Reply option on the 8n alignment constraint. (The original text says "CARD Request option" here, which is a copy-paste slip, but the rule is the same: keep each sub-option 64-bit aligned so the whole thing hits 8n.)
5.1.3. Sub-Options Format
sub-options are the little accessories that go inside those options, and every single one follows the same pattern 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Sub-Option Data . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Sub-Option Type: an 8-bit identifier for the type of option. The table below lists the sub-options defined in this document, and it also shows which interfaces each one is valid on.
Description Type Interface
| | / \
| | MN-AR AR-AR
---------------------------------------------------------------
L2 ID 0x01 x
Address 0x02 x
Capability Container 0x03 x x
Preferences 0x04 x x
Requirements 0x05 x
Trusted Anchor 0x06 x
Router Certificate 0x07 x xSub-Option-Length: an 8-bit unsigned integer for the length of the sub-option, counting the sub-option type and length fields too. Lengths are in units of 8 octets and sit on a 64-bit boundary. Shorter sub-options get padded with null octets, and how much padding you need depends on what's inside the sub-option 🧸.
5.1.3.1. L2 ID Sub-Option
this one's the star of the show when it comes to Layer-2 identifiers 🌟
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Context-ID | Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-Type | L2 ID . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -Sub-Option Type:0x01.Sub-Option Length: the length of the sub-option.Context-ID: ties together the L2 ID, IP address and other parameters that belong to the same AR IP address but come in separate sub-options. It's the glue 🧷.Status Code: lets ARs tell the requesting entity what happened when they processed a particular L2 ID. The L2 ID sub-option MUST be sent back to the requesting entity in a CARD Reply message. No skipping! 🙅♀️
These status codes are specified:
0x00NONE: this value MUST be set when the L2 ID is included in a CARD Request.0x01CANDIDATE: MUST be set in a CARD Reply when an L2 ID sub-option carries info about candidate APs' L2 IDs. Candidate L2 IDs get sent if the CARD Request didn't include a specific L2 ID to resolve. IfCANDIDATEis set, the AR MUST set the Context-ID field of each parameter so the associated L2 ID, address, and capability info can be matched up on the receiver side. Matching energy 💜.0x02MATCH: MUST be set in the CARD Reply to show that this L2 ID matches previously resolved CAR info for a different L2 ID. IfMATCHis set, the AR sets the Context-ID in the L2-ID sub-option to point at the matching previously resolved L2 ID. Cute little callback 🦋.0x03RESOLVER ERROR: MUST be set in the CARD Reply if the L2 ID can't be resolved. The AR sets this value for the Status Code in the returned L2 ID sub-option. Oof, that's a bad day 😭.
Okay real quick, the code point forNONEis0x00, and that's not the same as a sub-option Type. Don't mix those up, bestie 🫶.
L2 type: indicates the interface type. IANA allocates these values [Ke04].L2 ID: the variable-length Layer-2 identifier of an individual CAR's access point. The length without padding depends on the L2 type 🌸.
5.1.3.2. Preferences Sub-Option 🎀
Okay bestie, this one is the Preferences sub-option 💖 It's basically a shortlist of the capabilities the requesting side actually cares about, so the other side doesn't have to dump its whole menu. Super handy for optimization ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Preferences
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Sub-Option Type:0x04🍓Sub-Option Length: Length of the sub-option.Preferences: A list of capability attribute values (see Section 5.1.4) 💜
Here's the tea 🫖 Only the ATTRIBUTE fields (the AVP Code, see Section 5.1.4) MUST be present and set, and only for the individual capabilities the requesting entity is interested in. The LIFETIME and VALUE (Data) indicator won't get processed, so they can be left out. There's also no AVP LENGTH indicator, because preferences are just a list of 16-bit encoded ATTRIBUTE fields. If the list can't fill a 64-bit boundary cleanly, you MUST pad the missing 16-bit slot with an ATTRIBUTE value of 0x0000. And 0x0 is reserved on purpose 🦋 It marks the end of the list, so when you read a 0x0 you know you've hit the finish line.
The Preferences sub-option is optional, and it's purely for optimization 🌈
5.1.3.3. Requirements Sub-Option 🧚
Next up is the Requirements sub-option, which is kind of the Preferences' bossy cousin 👑 Instead of a simple list, it carries AVP-encoded requirements.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Sub-Option Type:0x05🌸Sub-Option Length: Length of the sub-option.Requirements: AVP-encoded requirements (see Section 5.1.4)
The AVPs MUST be encoded according to the rule in Section 5.1.4 💅 Both the ATTRIBUTE (AVP Code) and VALUE (Data) fields MUST be present and set properly. You know the Requirements list is over when you read an ATTRIBUTE value of 0x0, so keep an eye out for that 👀
Also, the Requirements sub-option is optional and is there for optimization purposes. Bestie, we love an optional optimization 💖
5.1.3.4. Capability Container Sub-Option ✨
This is the Capability Container sub-option, and it's a whole vibe 🎀 It's basically the wrapper that holds a bunch of AVPs describing what a router can do, and it also says whether that router can piggyback.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Context-ID |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVPs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -Sub-Option Type:0x03🦋Sub-Option Length: Length of the sub-option.Context-ID: Ties together the L2 ID, the IP address, and other parameters that belong to the same AR IP address but are encoded in separate sub-options. It's the glue, bestie 🫶Flags: The P-flag indicates the piggybacking capability of the CAR whose capabilities are carried in this Capability Container. This is the flag that lets an MN figure out, after a CARD process, whether a newly selected AR can do piggybacking 🔥Reserved: Initialized to zero, and ignored on receipt. 🤍AVPs: AVPs are how we encapsulate the capability info that's relevant to the CARD protocol. Check Section 5.1.4 for the AVP encoding rule and how the list gets parsed 💜
5.1.3.5. Address Sub-Option 🌈
Now the Address sub-option, which tells you where the Candidate Access Router actually lives 🏠 IP-wise, obviously 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Context-ID | Address Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -Sub-Option Type:0x02🍓Sub-Option Length: Length of the sub-option. For IPv4 the length is1(8 octets), and for IPv6 the length is3(24 octets). Math checks out 🧮Context-ID: Same idea as before. It links the L2 ID, IP address, and other parameters that belong to the same AR IP address but live in separate sub-options 🫶Address Type: Tells you what kind of address this is. ✨
0x01 IPv4
0x02 IPv6Address: The Candidate Access Router's IP address 🌸
5.1.3.6. Trusted Anchor Sub-Option 👑
Time for the Trusted Anchor sub-option 🔐 This one is all about asking for certificates in a certification path, and it's pretty specific about how you do it.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trusted Anchor Name
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -Sub-Option Type:0x06💖Sub-Option Length: Length of the sub-option.Reserved: Initialized to zero, and ignored on receipt. 🤍Component: A 2 octet unsigned integer field. It's set to65,535if the sender wants to retrieve all the certificates in the certification path. Otherwise, it's set to the component identifier for the one certificate the receiver wants to grab 🎯Trusted Anchor Name: The DER encoding for the X.501 name of the certification path component(see [Arkko04] for more detail on certification path component name encoding). 📜
Here's the rule, and it's a strict one 🙅♀️ A CARD Request message that contains Trusted Anchor sub-options MUST NOT contain any other sub-options, except for one single L2 ID sub-option that identifies the AP of interest. No sneaking in extra stuff!
Also, Trusted Anchor sub-options SHOULD be retransmitted for individual components that haven't been received within CARD_REQUEST_RETRY seconds, rather than re-requesting the whole list. Subsequent retransmissions SHOULD take into account whatever options were already received, and only ask for the ones that are still missing. Efficiency is everything 😭✨
5.1.3.7. Router Certificate Sub-Option 🔥
Last sub-option, and it's the big one: the Router Certificate sub-option 🏆 This is what actually carries the certificate chain back in a CARD Reply.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type|Sub-Option Len | Context-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All Components | Component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Certificate... |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Sub-Option Type:0x07🌈Sub-Option Length: Length of the sub-option.Context-ID: Links the L2 ID, the IP address, and other parameters that belong to the same AR IP address but are encoded in separate sub-options 🫶Reserved: Initialized to zero, and ignored on receipt. 🤍All Components: A 2 octet unsigned integer giving the total number of certificates in the certification path. 🧾Component: A 2 octet unsigned integer giving the location of this certificate in the certification path. 📍Certificate: A variable-length field holding the X.509v3 router certificate encoded in ASN.1 (see [Arkko04] for more detail on a certificate profile that includes encoding). 📜Padding: A variable-length field that makes the option length a multiple of 8. It starts right after the ASN.1 encoding of the certificate and runs to the end of the option, as set by the Length field. 🧸
Now for the rules, and there are a few 🧐 A CARD Reply containing a Router Certificate sub-option MUST NOT include more than one such sub-option. The CARD Reply MUST contain the matching L2 ID sub-option and router Address sub-option for the router that has the chain, with the Context-ID field set to a nonzero value, and with no other sub-options. Any other sub-options in a CARD Reply SHOULD be ignored. If the reply gets split across multiple ICMP messages, the L2 ID sub-option and router Address sub-option MUST be included in the first message sent, and the Context-ID field in the Router Certificate sub-options in all the messages MUST be set to the same value as in the L2 ID and Address sub-options. That's a lot of matching, bestie, but it keeps everything connected 💅
The replying AR SHOULD order the returned certification path so that the certificate right after the trust anchor is the first one sent. That way verification can happen immediately 🚀 And the trust anchor certificate itself SHOULD NOT be sent. It's already trusted, so it doesn't need to show up 🙈
5.1.4. Capability AVP Encoding Rule 💜
Here's how the capability AVPs get encoded 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code | AVP Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Lifetime | Data . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -AVP Code: Identifies the attribute uniquely. The0x0000AVP Code is reserved, so it MUST NOT be assigned to a capability 🚫AVP Length: The 2 octet AVP length field, which counts the octets in this AVP, including the AVP Code, AVP Length, Reserved, Lifetime, and Data fields. 📏Reserved: Initialized to zero, and ignored on receipt. 🤍Lifetime: How long the encoded capability lasts, in seconds. For a static capability, theLifetimefield MUST be set to the maximum value (0xffff), which means that capability parameter never expires ♾️ ALifetimevalue of0x0000deletes the capability entry. Bye bye 👋Data: A variable-length field that carries the encoded Value of the capability attribute 🎁
Because an AVP Code of 0x0 is reserved, the sub-option list parsing can use it to spot the end of a list of Capabilities and to find where the sub-option padding starts. AVPs themselves are not zero padded 🧠
Note: This document provides no detailed information on how to encode the individual capability attribute values, which is to be encoded in the Data field. Details on the interpretation of individual capability parameters are out of the scope of this document. So if you're looking for the exact encoding of each value, you'll need to look somewhere else 📚
5.2. CARD Inter-Access Router Messages 🌸
5.2.1. AR-AR Transport ✨
Okay so the access networks where CARD could be useful either aren't deployed yet or, if they are, nobody has measured them much 😭. That means we genuinely don't know if congestion will be a problem for inter-router CARD. Quantifying that is part of the research homework before CARD can even be considered for standardization 📚. But if a prototype runs over the public Internet, it could interfere with production apps, so it seems prudent to recommend a default transport that accommodates congestion 🫶.
This suggests that implementations of CARD MUST support and that prototype deployments of CARD SHOULD use the Stream Control Transport Protocol (SCTP) [Stew00] as the transport protocol between routers, especially if deployment over the public Internet is contemplated 💅. SCTP supports congestion control, fragmentation, and partial retransmission based on a programmable retransmission timer. It also has a bunch of advanced features, like multiple streams and multiple IP addresses for failover, that aren't necessary for experimental implementation and prototype deployment of CARD 🙈. The use of these SCTP features for CARD is not recommended at this time.
The SCTP Payload Data Chunk carries the CARD messages 🎀. On the inter-router interface, CARD messages consist of just the CARD Request or CARD Reply options. The User Data part of each SCTP message contains the CARD option for that message type. For example, a CARD Reply message is built by putting the CARD Reply option and all the appropriate sub-options inside the User Data part of an SCTP message.
A single stream is used for CARD, with in-sequence delivery of SCTP messages 🦋. Each message, unless it's fragmented, corresponds to a single CARD query or response. Unsolicited CARD Reply messages can also be sent to peers to tell them about changes in network configuration or capabilities 🌸. A single stream keeps things simple. Using multiple streams to prevent head-of-line blocking is for future study. Timeliness isn't an issue with inter-router CARD, and having more than one CARD transaction between two routers active at once is unlikely, so ordered delivery makes the implementation easier 🧚. The Payload Protocol Identifier in the SCTP header is 'CARD'. CARD uses the Seamoby SCTP port number [Ke04].
The format of the Payload Data Chunk, taken from [Stew00], is shown in the following diagram 👑.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'U' bit The Unordered bit. MUST be set to 0 (zero).
'B' bit The Beginning fragment bit. See [Stew00].
'E' bit The Ending fragment bit. See [Stew00].
TSN Transmission Sequence Number. See [Stew00].
Stream Identifier S
Identifies the CARD stream.
Stream Sequence Number n
Sequence number. See [Stew00].
Payload Protocol Identifier
Set to 'CARD'.
User Data Contains the CARD message.In order to avoid generating congestion on startup 🚦, ARs MUST wait a random amount of time between 0 and CARD_STARTUP_WAIT seconds upon reboot before sending an AR-AR CARD Request to one of its CARs. An AR that receives a CARD Request from another AR that isn't in its CAR table MUST NOT solicit the AR, but rather MUST wait until that AR sends an unsolicited CARD Reply advertising its information 🙅♀️. An AR that is starting up MUST send unsolicited CARD Replies to all its CARs so their CAR tables get properly populated ✨.
The frequency of unsolicited CARD Reply messages MUST be strictly limited to CARD_MIN_UPDATE_INTERVAL, so CARs don't get overwhelmed with traffic 💜. ARs are free to discard messages that arrive more frequently.
If a CARD deployment will never run over the public Internet, and it's known that congestion isn't a problem in the access network, alternative transport protocols MAY be appropriate vehicles for experimentation 🧪. Implementations of CARD MAY support UDP for such purposes. In that case, the researcher MUST be careful to follow good Internet transport protocol engineering practices, such as using retransmits with exponential backoff 🙏. Also, whether SCTP is an appropriate transport protocol for all inter-router CARD operations is an open research question. Investigating this (for example, to find out whether a lighter-weight protocol might be a better fit than SCTP) may be of interest to some researchers 🔍.
5.2.2. Protocol Payload Types 📦
The AR-AR interface MUST insert the CARD Request option and CARD Reply option directly into the body of the SCTP User Data field 💖. The sequence number for the CARD Request on the AR-AR interface MUST be initialized to zero when the AR reboots, and MUST be incremented every time a CARD Request message is sent. The replying AR MUST include a sequence number from the CARD Request in the CARD Reply. If an unsolicited CARD Reply is sent, the sending AR MUST increment the sequence number. Sequentially increasing sequence numbers let the receiving AR figure out whether it has already received the information 🔢.
On the AR-AR interface, the Capability Container parameter is used to convey capabilities between ARs 🌈. Optionally, the Preferences parameter can be used for capability pre-filtering during the inter-AR capability discovery procedure. Payload types and encoding rules are the same as the ones described for the respective sub-option types in Section 5.1 for the MN-AR interface 🫶. The same TLV-encoded format is used to attach the options as payload to the protocol main header. Also, an AR can set the T flag in the CARD Request header to obtain the certificates for the CAR 🎫. Section 5.1.3 includes information on which flag settings are prohibited on the AR-AR interface, so go check that one out 👀.
6. Security Considerations 🛡️
6.1. Veracity of CARD Information 🕵️♀️
Okay this one is kind of a big deal 😳. The veracity of the CARD protocol depends on an AR being able to get accurate information about geographically neighboring ARs, and on it giving accurate information about its own APs and capabilities to other ARs. The CARD protocol described in the body of this document has no support for determining the AR-to-AP mapping or capabilities, either for a specific AR or for a CAR. So methods for checking the accuracy of the information exchanged between ARs are out of scope for the base CARD protocol 🙃. The appendices of this document describe procedures for discovering the identities of the geographically adjacent ARs and APs (including capabilities), and they discuss relevant security considerations. Alternatively, this information could be statically configured into the AR 📝.
6.2. Security Association between AR and AR 🔐
CARD lets ARs exchange capability information, and that's exactly why it needs protecting 🚨. If this protocol isn't protected from modification, a malicious attacker can change the information. And if the information is delivered in plain text, a third party can read it 👀.
To keep the information from being compromised, the CARD messages between ARs MUST be authenticated 🔒. The messages also SHOULD be encrypted for privacy of the information, if required. Confidentiality might be required if the traffic between two ARs in an operator's network traversed the public Internet, for example 🌐.
Two ARs engaging in the CARD protocol MUST use IKE [HarCar98] to negotiate an IPsec ESP security association for message authentication. If confidentiality is desired, the two ARs MUST additionally negotiate an ESP security association for encryption. Replay protection SHOULD also be enabled with IKE. To protect CARD protocol messages between ARs, IPsec ESP [AtKe98] MUST be used with a non-null integrity protection and origin authentication algorithm, and SHOULD be used with a non-null encryption algorithm for protecting the confidentiality of the CARD information 🧱.
An AR can provide the certificates for its CARs if the certificates are available 🎀. The AR requests certificates from its CARs by setting the T flag in the CARD Request message. All certificates are sent.
If CARD is used to exchange information between different administrative domains, additional security policy issues may apply 🏢. Those issues are out of the scope of this document. Use of CARD between administrative domains is not recommended at this time, until the policy issues involved are more thoroughly understood ⏳.
6.3. Security Association between AR and MN 📡
A malicious node can send bogus CARD Reply messages to MNs by masquerading as the AR 😈. The MN MUST authenticate the CARD Reply messages from the AR. Since setting up an IPSec security association between the MN and AR is likely to be a performance issue, IKE isn't an appropriate mechanism for establishing it. Instead, the SEND security association is used [Arkko04]. ARs MUST include a SEND Signature Option on CARD Reply messages. The format of the signature option is the same for both IPv4 and IPv6 CARD, though SEND itself is only defined for IPv6. A Mobile IPv4 ICMP Foreign Agent Advertisement option type code for the SEND signature option [Ke04] has been allocated 🧾.
No authentication is required for CARD Requests, since CARD information is provided by the AR to optimize link access ⚡. In contrast, CARD Reply authentication is required, because a bogus AR could feed the MN CARD information that gets it to hand over to a bogus router. That router could steal traffic or launch a denial of service attack on the MN 💀. The asymmetry of this authentication requirement is the same as the one involving Router Advertisements in IPv6 router discovery [Arkko04] 🪞.
Since CARD is a discovery protocol, confidentiality is not generally necessary on the MN-AR interface 🫧. In specific cases where different network operators share the same access network infrastructure, those operators may want to hide information about operator-specific capabilities for business reasons. The base CARD protocol contains no support for such cases. However, if that situation comes up in the future, an AVP for an encrypted capability can be defined at that time 🔮.
6.4. Router Certificate Exchange ✨
okay so SEND is only available in IPv6 🫶, which means the way you get certificates is different depending on whether CARD is running over IPv4 or IPv6. Let's do IPv6 first. When the MN gets a CARD reply signed by an AR it has no certificate for, it SHOULD use SEND DCS/DCA to grab the AR's certificate chain 🔐. ARs MUST be configured with a certification path for this purpose 💅, and MNs MUST be configured with a set of certificates for shared trusted anchors so they can verify the AR certificates. An MN may not necessarily need Cryptographically Generated Addresses (CGAs) with CARD, so CGA support is OPTIONAL for CARD. The certificate profile for ARs lives in the SEND spec [Arkko04] 📜.
Now IPv4, which is the messier one 🙈. There's no DCS/DCA message for getting the certificate here. So if the MN doesn't have a certificate for the AR, it sends a CARD Request with the L2 ID of its current AP and one Trusted Anchor sub-option (Section 5.1.3.6) for each shared trusted anchor it has a certificate for, to get the certification path for the current AR. The Component field of the Trusted Anchor sub-option is set to 65535, which basically says "I want the whole path, bestie" 🌈. No other options should be included in the request.
The AR replies with a CARD Reply that includes the L2 ID sub-option from the request, an Address sub-option for itself, and a Router Certificate sub-option (Section 5.1.3.7) holding one certificate from its path that matches one of the requested trust anchors. That's it, no other sub-options 🎀. Every sub-option gets the same Context-ID. The All Components field is set to the path length, and the Component field is set to this certificate's position in the path ✨.
If the path is longer than one certificate, the AR sends the L2 ID sub-option and the Address sub-option in the first certificate, and the rest of the certificates go in separate ICMP messages 🦋. Why? Because ICMP messages have a length limit and it's giving tight space 😭. Each one keeps the same Context-ID on its Route Certificate sub-option, with the Component field set properly. The router SHOULD NOT send the trusted anchor's certificate, and SHOULD send the certificates in order, starting from the one after the trusted anchor 🍓. If the trusted anchor option doesn't match any certificate, the AR sends the Trusted Anchor sub-options back in the reply 💀.
Last thing in this bit: the MN SHOULD immediately run a Certificate Revocation List (CRL) check on any certificate it got through CARD certificate exchange, just to make sure it's still valid 🔍. Main character energy is checking your receipts 💜.
Certification paths for CARs can be fetched before handover too 🧚. In that case, the MN includes Trusted Anchor sub-options in the CARD request, along with the L2 ID sub-option for the AP where it wants the CAR certificate. The AR replies the same way as above, except the L2 ID, address, and certificates are for the CAR instead of the AR itself ✨. The payoff is that the MN can skip the DCS/DCA or CARD certificate exchange when it moves to a new router 🚀.
Because the amount of space in an ICMP message is limited, the router certification paths SHOULD be kept short 🫶.
6.5. DoS Attack 🚨
An AR can get overwhelmed with CARD Request messages 😩. So the AR SHOULD implement a rate-limiting policy, so it doesn't send or process more than a certain number of messages per period. Here's a suggested rate limiting policy 💅. If the number of CARD messages goes over CARD_REQUEST_RATE, the AR SHOULD start randomly dropping messages until the rate comes down. MNs SHOULD avoid sending messages more often than CARD_REQUEST_RATE. ARs SHOULD also avoid sending unsolicited CARD Replies or CARD Requests more often than CARD_MIN_UPDATE_INTERVAL. But here's the thing, in this case the IPsec security association already means messages from unknown entities get tossed right away during IPsec processing 🛡️. Iconic protection honestly 👑.
And then there's this one, which is non-negotiable 🙅♀️: MNs MUST discard CARD Replies for which there is no outstanding CARD Request, as indicated by the sequence number.
6.6. Replay Attacks 🔁
To protect against replay attacks on the AR-AR interface, ARs SHOULD enable replay protection when negotiating the IPsec security association using IKE 🔐.
On the MN-AR interface, the MN MUST discard any CARD Replies for which there is no outstanding request, as determined by the sequence number 🚫. For ARs, an attacker can replay a previous request from an MN, but it's not a big deal because the MN ignores the reply in any case 🙄. Honestly that's lowkey a win 💖.
7. Protocol Constants 🌸
Constant Section Default Value Meaning
--------------------------------------------------------------------
CARD_REQUEST_RETRY 5.1.1 2 seconds Wait interval before
initial retransmit
on MN-AR interface.
CARD_RETRY_MAX 5.1.1 15 seconds Give up on retry
on MN-AR interface.
CARD_STARTUP_WAIT 5.2.1 1-3 seconds Maximum startup wait
for an AR before
performing AR-AR
CARD.
CARD_MIN_UPDATE_INTERVAL 5.2.1 60 seconds Minimum AR-AR update
interval.
CARD_REQUEST_RATE 6.5 2 requests/ Maximum number of
sec. messages before
AR institutes rate
limiting.8. IANA Considerations 📋
See [Ke04] for instructions on IANA allocation 🧾.
9. Normative References 📚
[Brad97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Stew00] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[AtKe98] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[HarCar98] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[Arkko04] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[Ke04] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
10. Informative References 🧠
[TKCK02] Trossen, D., Krishanmurthi, G. Chaskar, H., Kempf, J., "Issues in candidate access router discovery for seamless IP-level handoffs", Work in Progress.
[MaKo03] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[Kood03] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[Funa02] Funato, D., et al., "Geographically Adjacent Access Router Discovery Protocol", Work in Progress.
[Tros03] Trossen, D., et al., "A Dynamic Protocol for Candidate Access-Router Discovery", Work in Progress.
[ShGi00] Shim, E. and R. Gitlin, "Fast Handoff Using Neighbor Information", Work in Progress.
[Malk03] El Malki, K., et al., "Low Latency Handoffs in Mobile IPv4", Work in Progress.
11. Contributors 🫂
The authors would like to thank Vijay Devarapalli (Nokia) and Henrik Petander (Helsinki University of Technology) for formally reviewing the protocol specification document and providing valuable comments and input for technical discussions. The authors would also like to thank James Kempf for reviewing and for providing a lot of valuable comments and editing help 💜.
12. Acknowledgements 🎉
The authors would like to thank (in alphabetical order) Dirk Trossen, Govind Krishnamurthi, James Kempf, Madjid Nakhjiri, Pete McCann, Rajeev Koodli, Robert C. Chalmers, and other members of the Seamoby WG for their valuable comments on the previous versions of the document, as well as for the general CARD-related discussion and feedback ✨. In addition, the authors would like to thank Erik Nordmark for providing valuable insight about the piggybacking of CARD options upon Fast Mobile IPv6 messages 🦋.
Appendix A. Maintenance of Address Mapping Tables in Access Routers 🗂️
This appendix provides information on two optional CAR table maintenance schemes for reverse address mapping in access routers 🌈. These schemes replace static configuration of the AP L2 ID-to-CAR IP address mapping in the CAR table. Details on these mechanisms are out of the scope of this document. The intention of this appendix is to provide only a basic idea on flexible extensions to the CARD protocol, as described in this document 🧚.
Appendix A.1. Centralized Approach Using a Server Functional Entity 🌸
okay so the centralized approach does CARD over the MN-AR interface exactly like Section 4 of this document 💅 but it also brings in a brand new entity, the CARD server 🧚, to help the current AR do reverse address translation. the neighboring ARs have to register with the CARD server so it can fill up the reverse address translation table. and that registration happens before any reverse address translation request even shows up 🫶
Figure A.1 shows a typical centralized CARD situation where the ARs already registered their address info with the server ahead of time 🎀 when an MN picks up the L2 ID of some APs during L2 scanning, it hands one or more of those L2 IDs to its current AR, and the AR turns them into the IP address of the AR ✨ the AR checks its own CAR table first. if the mapping isn't in there, the MN's current AR asks the CARD server about that L2 ID 🙈 the server sends back the IP address of the CAR, the current AR goes straight to that CAR and does capability discovery with it, and then it passes the CAR's IP address and its capabilities along to the MN 💖 finally, the current AR saves the resolved IP address in its local CAR table 🦋
the centralized version does come with extra signaling messages between the MN's current AR and the CARD server 😭 those messages are labelled with the prefix "AR-Server", which just tells you which interface they're on 🍓
fun fact, this whole idea was first floated in [Funa02] 🌈
+----------+
+------------>| CARD |<-------------+
|+------------| Server |-------------+|
|| +----------+ ||
|| ||
|| ~~~~~~~~~~~ ||
(3)AR-Server||(4)AR-Server{ } ||(0) CARD
CARD || CARD { } ||Reg Req/
Request || Reply { IP Cloud } | Reply
|| { } ||
|| { } ||
|V ~~~~~~~~~~~ V|
+---------+ (5)AR-AR CARD Request +-----+-----+
| Current |------------------------->| CAR | CAR |
| AR |<-------------------------| 1 | 2 |
+---------+ (6)AR-AR CARD Reply +-----+-----+
^ | | |
(2)MN-AR | |(7)MN-AR | |
CARD | | CARD | |
Request| V Reply +---+ +---+
+--------------+ (1) AP1 L2 ID +--|AP1| |AP2|
| Mobile |<---------------------+ +---+ +---+
| Node |<--------------------------------+
+--------------+ (1) AP2 L2 ID
Figure A.1: Centralized Approach for L2-L3 MappingAppendix A.2. Decentralized Approach Using Mobile Terminals' Handover 🦋
this one also does CARD over the MN-AR interface like Section 4 👑 but it adds ONE extra message, the Router Identity message, over that same MN-AR interface 🌸 so the ARs can learn about each other's reverse address translation tables without needing any centralized server. no server drama, just vibes 🫶
in this approach, the CAR identities in an AR's CAR table are soft state ✨ which means they get removed if they're not refreshed before the timeout period runs out 💀 they get created or refreshed following the mechanism below 💅
the big idea is to bootstrap and then maintain the association between two ARs as neighbors of each other, using the actual handovers of MNs between them as the input 🧚 the very first handover between two neighboring ARs is the bootstrap handover that kicks off discovery 🎀 after that, each later handover refreshes the association 💖 once the bootstrap is done, MNs can do CARD and get seamless handover using the CAR info 🌈 this idea was presented in [ShGi00] and [Tros03] 🙌
the CAR table is maintained with an additional option for the CARD protocol operation between an MN and its current AR 🍓 and that message doubles as the Router Identity message 💜
upon completing an inter-AR handover, the MN SHOULD send a Router Identity message to its current AR 🫶 this message carries the identity (IP address) of the previous AR (pAR), and it can ride along as a specific sub-option in the MN-AR CARD Request message ✨ it SHOULD be acknowledged with the MN-AR CARD Reply 🌸 the Router Identity message lets the MN's current AR figure out that the pAR (still) has an AP whose coverage overlaps with one of the current AR's APs, and vice versa 👑 with that info, the current AR can create or refresh an entry for the pAR as a neighbor 🦋 if handover isn't possible between the two ARs anymore, those entries eventually time out and get removed from each AR's CAR table 💀
before trusting the MN's report, though, the current AR may run a few checks to make sure the info is legit 🙈 one simple method is to check the Router Identity message by sending an AR-AR CARD Request to the pAR, and that request includes the MN's identity 🎀 the pAR then verifies the MN was indeed attached to it during a reasonable past interval and replies to the current AR 💖 so every handover ends up as a bi-directional discovery process between the two ARs 🔥
if the pAR sends back a positive verification response, the current AR creates or refreshes the pAR's entry in its local CAR table, as applicable 🌈 when it's a new entry, the current AR and the pAR swap capabilities using the AR-AR CARD Request and AR-AR CARD Reply protocol messages ✨ and when a new entry is created, the ARs MUST exchange their reverse address translation tables 💅 they may also exchange other capabilities at that point, or they can wait until later, when some MN handing over between them does CARD as described in Section 4 🧚 in the refresh case, the ARs may exchange capabilities, or they can put it off until another MN goes through a handover 🫶
last thing: in a handover-based protocol, a first handover between a pAR and an MN's current AR can't use CARD, because that handover is what bootstraps the CAR table 😭 but in the long run, that kind of handover is only a tiny slice of all the successful handovers between the two ARs 🍓 and if the MN doing that first handover is running a non-delay-sensitive application at the time, the user might not even notice 🌈✨
Appendix B. Application Scenarios 🎀
this section gives two examples of application scenarios for CARD protocol operation 💜 the first one is a CARD operation in a Mobile IPv6 (MIPv6) network, which gives access to the infrastructure through wireless LAN Access Points and their associated Access Routers 🦋 the second one is a CARD operation in a Mobile IPv6-enabled network with fast handover support built in (Fast Mobile IPv6), which also gives wireless LAN access to the infrastructure 👑
this scenario assumes a moving MN that reaches the infrastructure through wireless LAN (IEEE802.11) APs 🌸 mobility management is handled by the Mobile IPv6 protocol 🫶 the figure below shows the access network design we're assuming ✨
Appendix B.1. CARD Operation in a Mobile IPv6-Enabled Wireless LAN Network ✨
-----------------------------
/ \ +----+
| NETWORK |---| HA |
\ / +----+
-----------------------------
| |
+-----+ +-----+
| AR1 |---------+ | AR2 |
+-----+ | +-----+
| subnet 1 | |subnet 2
+-----+ +-----+ +-----+
| AP1 | | AP2 | | AP3 |
+-----+ +-----+ +-----+
^ ^ ^
\
\
\
v
+-----+
| MN | - - ->>>- - - ->>>
+-----+Figure B.1: Assumed Network Topology
okay so picture a Mobile IPv6 Home Agent (HA) 🏠 keeping track of where the MN is in its binding cache 🧚. In Figure B.1, the MN has a care-of address on subnet 1, served by AR1. As the MN moves around, it spots two more wireless LAN APs with better and better link quality, so they're candidates for a handover 🦋. To make the call, the MN looks at AR-related parameters too, like available QoS resources or the kinds of access technologies an AR supports. These are the vibes that matter when picking a spot 💅.
To learn about those candidate ARs' capabilities and their IP address info, the MN does CARD 🎀. That means it needs to grab the L2 IDs of the candidate APs, and it also needs their link-quality parameters so it can figure out if the approaching APs are actually eligible for a handover. Say AP2 and AP3 both look good 👀. The MN stuffs both L2 IDs (AP2 and AP3) into a CARD Request message using the L2 ID sub-option, and sends it off to its current AR, which is AR1 🌸.
AR1 takes each L2 ID from the L2 ID options and turns it into the IP address of the matching CAR, using its own local CAR table 🗺️. In this setup, the AR IP address for candidate AP2 is the same one the MN is already attached to, which is AR1. The CAR for AP3 is AR2's address instead. Now AR1 knows the IP addresses of the MN's CARs, so it pulls their capabilities from the CAR table 💖. If it has valid entries for those capability parameters, great, but any dynamic capabilities whose lifetimes have expired in AR1's CAR table need a refresh. So AR1 runs Inter-AR CARD for capability discovery 🔥. AR1 already knows its own capability info, so the Inter-AR CARD Request only goes to AR2. AR2 replies with a CARD Reply message, and the requested capability parameters ride along inside a Capability Container sub-option 🧚♀️.
Next up, AR1 sends its own capabilities plus the freshly discovered ones from AR2 back to the MN in a CARD Reply message 💌. AR1 also saves AR2's capability parameters, along with their lifetimes, in its local CAR table so it's ready next time ✨.
When the MN gets that CARD Reply, it does target AR selection, weighing AR1's and AR2's capability parameters along with the APs' link-quality parameters 💅. If AP2 wins, there's no IP handover to worry about, bestie 🙌. If AP3 and its AR2 get picked, the MN has to do an IP handover following the Mobile IPv6 protocol operation 🌈.
Figure B.2 shows the signaling flow for this CARD scenario inside a Mobile IPv6-enabled network 🦋.
MN AP1 AR1 AP2 AP3 AR2
| | | | | |
| connected | | | | |
0-------------0-------0 | | |
| | | | | |
| | | | | |
| | | |
| <~~~~~~~~~L2-SCAN (AP2)~~~~~| | |
| <~~~~~~~~~L2-SCAN (AP3)~~~~~~~~~~~~~~~~~| |
| | | |
| (MN-AR) CARD Req | | | |
|-------------------->| (AR-AR) CARD Req |
| | |---------------------------------------->|
| | | (AR-AR) CARD Repl |
| (MN-AR) CARD Repl |<----------------------------------------|
|<--------------------| | | |
| | | | | |
[target AR | | | | |
selection] | | | | |
| | | | | |
// // // // // //
[either...] | | | | |
| | | | | |
|-------- L2 attach --------->| | |
| | | | | |
| connected | | | |
0---------------------0-------0 | |
| | | | | |
// // // // // //
[... or] | | | | |
| | | | | |
|--------------- L2 attach -------------->| |
| | | | | |
| connected | | | |
0-----------------------------------------0---------------------0
| | | | | |
| | |
| MIPv6 Binding Update to the HA | |
|------------------------------------------------ - - - > |
| | | | | |Figure B.2. CARD Protocol Operation within a Mobile IPv6-Enabled Wireless LAN Network
Appendix B.2. CARD Operation in a Fast Mobile IPv6 Network
This scenario assumes the ARs can run the fast handover protocol sequence for Mobile IPv6 [Kood03] 🫶. The MN scans for new APs to hand over to, same as in Figure B.1 👀. To find the ARs (CARs), the MN tacks a MN-AR CARD Request option onto the ICMP-type Fast Mobile IPv6 RtSolPr message, which goes to its current AR, the pAR (previous AR) 🧚.
The candidate APs' L2 IDs get wrapped up in the CARD protocol's L2 ID sub-options. These let the MN send a whole list of candidate AP L2 IDs to its current AR in one go 💜. (This can replace the "New Attachment Point Link-Layer Address" option of the Fast Mobile IPv6 protocol 🌸.)
The pAR turns that list of candidate AP L2 IDs into the IP addresses of the associated CARs 🗺️. Then it checks its local CAR table for those CARs' capabilities. If any entries have expired, the pAR goes and gets fresh capabilities by sending an AR-AR CARD Request to the right CAR 🔥. That CAR answers with an AR-AR CARD Reply message, packing all its capabilities into a Capability Container sub-option and attaching them to the CARD Reply option 💌. Once the pAR has the CARs' capability info, it updates its local CAR table and passes the addresses and capabilities on to the MN by attaching a MN-AR CARD Reply option to the Fast Mobile IPv6 PrRtAdv message 🦋.
When the handover is about to happen, the MN picks its new AR and the matching new AP from the list of discovered CARs 💅. Following the Fast Mobile IPv6 protocol, the MN tells the pAR which new AR it chose by sending a Fast Binding Update (F-BU) message. That lets the pAR run a fast handover per the Fast Mobile IPv6 protocol 🚀.
The pAR can also choose a suitable new AR on the MN's behalf 👑. It can do this once it has the MN's CARs' addresses and their capabilities. The MN must send its selection requirements to its pAR together with the MN-AR CARD Request message. After the pAR has picked the MN's new AR, the address and capabilities of that chosen AR go back to the MN in the CARD Reply option inside the Fast Mobile IPv6 PrRtAdv message ✨.
Figure B.3 shows how the CARD protocol messages and functions fit with the Fast Mobile IPv6 protocol 🧚♀️.
MN pAR NAR CAR2
| | as CAR1 |
| | | |
|-------RtSolPr------>| | |
| [MN-AR CARD Req] |-- AR-AR CARD Req*->| |
| |-- AR-AR CARD Req*------------>|
| |<--AR-AR CARD Repl*------------|
| |<--AR-AR CARD Repl*-| |
|<------PrRtAdv-------| | |
| [MN-AR CARD Repl] | | |
| | | |
NAR selection | | |
|------F-BU---------->|--------HI--------->| |
| |<------HACK---------| |
| <--F-BACK--|--F-BACK--> | |
| | | |
Disconnect | | |
| forward | |
| packets===============>| |
| | | |
| | | |
Connect | | |
| | | |
RS (with FNA option)======================>| |
|<-----------RA (with NAACK option)--------| |
|<=================================== deliver packets |
| | |Figure B.3. Fast Handover Protocol Sequence with CARD Protocol Options
- In Figure B.3, the CARD protocol interaction between the pAR and CARs is only required if the lifetime of any capability entries in the pAR's CAR table have expired. Otherwise, the pAR can respond to the requesting MN immediately after retrieving the CARs' addresses and capability information from its CAR table 💅.
Authors' Addresses ✨
okay bestie, here are the five people who wrote this RFC and where to find them 🧚 each address is in a code block so you can copy the details exactly 💅
Hemant Chaskar
AirTight Networks
339 N. Bernardo Avenue
Mountain View, CA 94043, USA
EMail: hemant.chaskar@airtightnetworks.netDaichi Funato
NTT DoCoMo, Inc.
Communication Systems Laboratory
Wireless Laboratories
3-5, Hikarinooka, Yokosuka,
Kanagawa 239-8536, Japan
Phone: +81-46-840-3921
EMail: funato@mlab.yrp.nttdocomo.co.jpMarco Liebsch
NEC Network Laboratories
Kurfuersten-Anlage 36,
69115 Heidelberg, Germany
Phone: +49 6221-90511-46
EMail: marco.liebsch@netlab.nec.deEunsoo Shim
Panasonic Digital Networking Laboratory
Panasonic Corporation
Two Research Way
Princeton, NJ 08540
Phone: +1-609-734-7354
EMail: eunsoo@research.panasonic.comAjoy Singh
Motorola Inc
2G11, 1501 West Shure Dr.
Arlington Heights, IL 60004, USA
Phone: +1 847-632-6941
EMail: asingh1@email.mot.comFull Copyright Statement ✨
Copyright is held by The Internet Society (2005) 🦋
This document is covered by the rights, licenses and restrictions in BCP 78. Apart from what BCP 78 sets out, the authors keep all of their rights 💖
The legal bit is written in all caps, so here it is word for word:
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.In plain terms, the document comes "as is", and the contributor, their organization (if any), the Internet Society, and the IETF all say they don't guarantee it won't infringe anyone's rights or that it's merchantable or fit for a particular purpose 💀 ngl, very serious energy, but it's just the standard fine print.
Intellectual Property ✨
The IETF doesn't take a position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or how far they reach 🔥 It also doesn't say whether licenses under those rights are available. And it hasn't independently looked for any such rights either 👑 If you want the procedures for rights in RFC documents, check BCP 78 and BCP 79 🌸
Copies of IPR disclosures sent to the IETF Secretariat are available, along with any assurances of licenses to be made available. You can also see the results of any attempt to get a general license or permission to use the proprietary rights, for implementers or users of this specification. All of that lives in the IETF online IPR repository at http://www.ietf.org/ipr 🦋
If you know about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard, the IETF wants to hear about it 🫶 Send the info to ietf-ipr@ietf.org 💅
Acknowledgement ✨
Funding for the RFC Editor function is currently provided by the Internet Society 🌈 Thank you to the Internet Society for keeping the RFC Editor running, bestie 💜
📦 where this page comes from
- ietf: rfc4066 2005-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms