GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4066

Network Working Group M. Liebsch, Ed. Request for Comments: 4066 A. Singh, Ed. Category: Experimental H. Chaskar

                                                             D. Funato
                                                               E. Shim
                                                             July 2005
              Candidate Access Router Discovery (CARD)

Status of This Memo

 This memo defines an Experimental Protocol for the Internet
 community.  It does not specify an Internet standard of any kind.
 Discussion and suggestions for improvement are requested.
 Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).

Abstract

 To enable seamless IP-layer handover of a mobile node (MN) from one
 access router (AR) to another, the MN is required to discover the
 identities and capabilities of candidate ARs (CARs) for handover
 prior to the initiation of the handover.  The act of discovery of
 CARs has two aspects: identifying the IP addresses of the CARs and
 finding their capabilities.  This process is called "candidate access
 router discovery" (CARD).  At the time of IP-layer handover, the CAR,
 whose capabilities are a good match to the preferences of the MN, is
 chosen as the target AR for handover.  The protocol described in this
 document allows a mobile node to perform CARD.

Table of Contents

 1.  Introduction..................................................  2
 2.  Terminology...................................................  3
 3.  CARD Protocol Functions.......................................  4
     3.1.  Reverse Address Translation.............................  4
     3.2.  Discovery of CAR Capabilities...........................  4
 4.  CARD Protocol Operation.......................................  4
     4.1.  Conceptual Data Structures..............................  7
     4.2.  Mobile Node - Access Router Operation...................  8
     4.3.  Current Access Router - Candidate Access Router
           Operation............................................... 11
     4.4.  CARD Protocol Message Piggybacking on the MN-AR
           Interface............................................... 13

Liebsch, et al. Experimental [Page 1] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 5.  Protocol Messages............................................. 14
     5.1.  CARD Messages for the Mobile Node-Access Router
           Interface............................................... 14
     5.2.  CARD Inter-Access Router Messages....................... 28
 6.  Security Considerations....................................... 31
     6.1.  Veracity of CARD Information............................ 31
     6.2.  Security Association between AR and AR.................. 31
     6.3.  Security Association between AR and MN.................. 32
     6.4.  Router Certificate Exchange............................. 32
     6.5.  DoS Attack.............................................. 34
     6.6.  Replay Attacks.......................................... 34
 7.  Protocol Constants............................................ 34
 8.  IANA Considerations........................................... 35
 9.  Normative References.......................................... 35
 10. Informative References........................................ 35
 11. Contributors.................................................. 36
 12. Acknowledgements.............................................. 36
 Appendix A.  Maintenance of Address Mapping Tables in
              Access Routers....................................... 37
     Appendix A.1. Centralized Approach Using a Server Functional
                   Entity.......................................... 37
     Appendix A.2. Decentralized Approach Using Mobile Terminals'
                   Handover........................................ 38
 Appendix B.  Application Scenarios................................ 40
     Appendix B.1. CARD Operation in a Mobile IPv6-Enabled Wireless
                   LAN Network..................................... 40
     Appendix B.2. CARD Operation in a Fast Mobile IPv6-Enabled
                   Network......................................... 43

1. Introduction

 IP mobility protocols, such as Mobile IP, enable mobile nodes to
 execute IP-level handover among access routers.  Work is underway
 [Kood03][Malk03] to extend the mobility protocols to allow seamless
 IP handover.  Seamless IP mobility protocols will require knowledge
 of candidate access routers (CARs) to which a mobile node can be
 transferred.  The CAR discovery protocol enables the acquisition of
 information about the access routers that are candidates for the
 mobile node's next handover.
 CAR discovery involves identifying a CAR's IP address and the
 capabilities that the mobile node might use for a handover decision.
 There are cases in which a mobile node has a choice of CARs.  The
 mobile node chooses one according to a match between the mobile
 node's requirements for a handover candidate and the CAR's
 capabilities.  However, the decision algorithm itself is out of the
 scope of this document.

Liebsch, et al. Experimental [Page 2] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 The problem statement for CAR discovery is documented in [TKCK02].
 In this document, a protocol is described to perform CAR discovery.
 Section 3 describes two main functions of the CAR discovery protocol.
 Section 4 describes the core part of the CARD protocol operation.
 The protocol message format is described in Section 5.  Section 6
 discusses security considerations, and Section 7 contains a table of
 protocol parameters.  Appendix A contains two alternative techniques
 for dynamically constructing the CAR table mapping between the access
 point L2 ID and Access Router IP address, which is necessary for
 reverse address translation.  The default method is static
 configuration.  Appendix B contains two sample scenarios for using
 CARD.

2. Terminology

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [Brad97].
 This document uses terminology defined in [MaKo03].
 In addition, the following terms are used:
 Access Router (AR)
    An IP router residing in an access network and connected to one or
    more APs.  An AR offers IP connectivity to MNs.
 Candidate AR (CAR)
    An AR to which an MN has a choice when performing IP-level
    handover.
 Capability of an AR
    A characteristic of the service offered by an AR that may be of
    interest to an MN when the AR is being considered as a handover
    candidate.
 L2 ID
    An identifier of an AP that uniquely identifies that AP.  For
    example, in 802.11, this could be a MAC address of an AP.

Liebsch, et al. Experimental [Page 3] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 CARD Initiating Trigger
    An L2 trigger used to initiate the CARD process.  For example, a
    MN can initiate CARD as soon as it detects the L2 ID of a new AP
    during link layer scan.
 Access Point (AP)
    A wireless access point, identified by a MAC address, providing
    service to the wired network for wireless nodes.

3. CARD Protocol Functions

 The CARD protocol accomplishes the following functions.

3.1. Reverse Address Translation

 If an MN can listen to the L2 IDs of new APs prior to making a
 decision about IP-level handover to CARs, a mechanism is needed for
 reverse address translation.  This function of the CARD protocol
 enables the MN to map the received L2 ID of an AP to the IP address
 of the associated CAR that connects to the AP.  To get the CAR's IP
 address, the MN sends the L2 ID of the AP to the current AR, and the
 current AR provides the associated CAR's IP address to the MN.

3.2. Discovery of CAR Capabilities

 Information about the capabilities of CARs can assist the MN in
 making optimal handover decisions.  This capability information
 serves as input to the target AR selection algorithm.  Some of the
 capability parameters of CARs can be static, whereas others can
 change with time.
 A definition of capabilities is out of the scope of this document.
 Encoding rules for capabilities and the format of a capability
 container for capability transport are specified in Section 5.

4. CARD Protocol Operation

 The CARD protocol allows MNs to resolve the L2 ID of one or more APs
 to the IP addresses of the associated CARs.  The L2 IDs are typically
 discovered during an operation by the MN and are potential handover
 candidates.  Additionally, CARD allows MNs to discover particular
 capabilities associated with the CARs, such as available bandwidth,
 that might influence the handover decision of the MN.  Furthermore,
 the protocol allows ARs to populate and maintain their local CAR
 table (Section 4.1) with the capabilities of CARs.  For this, the
 CARD protocol makes use of CARD Request and CARD Reply messages

Liebsch, et al. Experimental [Page 4] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 between an MN and its current AR (Section 5.1.2), and between an MN's
 current AR and individual CARs, respectively (Section 5.2.2).
 To allow an MN to retrieve a CAR's address and capability
 information, the CARD Request and CARD Reply messages used between an
 MN and its current AR may contain one or more access points' L2 IDs
 and the IP addresses of associated CARs, respectively.  Optionally,
 the CARD Reply messages can also contain a CAR's capability
 information.  A CAR's capabilities are specified as a list of
 attribute-value pairs, which are conveyed in a Capability Container
 message parameter.
 Information about CARs and associated capabilities MAY be used by the
 MN to perform target access router selection during its IP handover.
 The current AR returns replies according to its CAR table (see
 Section 4.1) and returns a RESOLVER ERROR (see Section 5.1.3.1) if
 the request cannot be resolved.
 The CARD protocol also enables an MN to optionally indicate its
 preferences on capabilities of interest to its current AR by
 including the Preferences message parameter in the CARD Request
 message.  The MN's current AR MAY use this information to perform
 optional capability pre-filtering for optimization purposes, and it
 returns only these capabilities of interest to the requesting MN.
 The format of this optional Preferences message parameter is
 described in Section 5.1.3.2.
 Optionally, the MN can provide its current AR with a list of
 capability attribute-value pairs, indicating not only the capability
 parameters (attributes) required for capability pre-filtering, but
 also a specific value for a particular capability.  This allows the
 MN's current AR to perform CAR pre-filtering and to send only address
 and capability information of CARs whose capability values meet the
 requirements of the MN back to the requesting MN.  The format of this
 optional Requirements message parameter is described in Section
 5.1.3.3.
 For example, using the optional Preferences message parameter, an MN
 may indicate to its current AR that it is interested only in
 IEEE802.11a interface-specific capability parameters, as this is the
 only interface the MN has implemented.  The MN's current AR sends
 back only CARs with IEEE802.11a-specific capabilities.  Similarly,
 using the optional Requirements message parameter, an MN may indicate
 to its current AR that it is only interested in CARs that can satisfy
 a given QoS constraint.  Here, an MN sends the respective QoS
 attribute with the QoS constraint value to its current AR using the
 optional Requirements message parameter.  The QoS constraint is
 denoted as an attribute-value pair and encapsulated with the

Liebsch, et al. Experimental [Page 5] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 Requirements message parameter, which is appended to the MN-
 originated CARD Request message.  The Requirements message parameter
 may be used to indicate the cutoff values of the capabilities for any
 desired CARs.  According to the received optional list of attributes
 in the Preferences parameter or a list of attribute-value pairs in
 the Requirements message parameter, the MN's current AR MAY use these
 parameters for deciding the content of the solicited CARD Reply
 message, which is to be sent back to the MN.  Alternatively, if the
 MN's current AR does not perform optimization with regard to
 capability or CAR pre-filtering, the current AR MAY choose to
 silently ignore the optional Requirements and Preferences message
 parameter as received in the CARD Request message.
 The MN can additionally request from the AR a certification path that
 is anchored at a certificate from a shared, trusted anchor.  The MN
 includes in the CARD Request message a list of trusted anchors for
 which the MN has a certificate, and the AR replies with the
 certification path.  If no match is found, the AR returns the trusted
 anchor names from the CARD Request.  The MN can ask for a chain for
 either the current AR or a CAR.  If the trusted anchor list is
 accompanied by an AP L2 ID for the MN's current AP, the returned
 chain is for the current AR.  If the L2 ID is for an AP that the MN
 has heard during scanning and is not connected to the current AR, the
 returned chain is for a CAR.  The chain is returned as a sequence of
 CARD Reply messages, each message containing a single certificate,
 the L2 identifier for the AP sent in the CARD Request, and a router
 address for the CAR (or for the AR itself if a request was made for
 the AR).  When the chain is complete, the MN can use it to obtain the
 AR's certified key and thereby validate signatures on CARD messages
 and other messages between the MN and the current AR.  The MN only
 has to send the trusted anchor option if it does not have the
 certification path for the AR already cached.  If the MN has the
 certification path cached, through preconfiguration, through previous
 receipt of the chain from this router, or by having received the
 chain through a previous router, then the trusted anchor does not
 have to be sent.  More information about certificate exchange and its
 use in CARD security can be found in Section 6.
 The CARD protocol operation, as described in this section,
 distinguishes signaling messages exchanged between an MN and its
 current AR from those exchanged between ARs.  Hence, descriptions of
 signaling messages in the following sections have preceding
 identifiers referring to the associated interface.  Messages that are
 exchanged between an MN and AR are designated as "MN-AR", and
 messages between ARs are designated as "AR-AR".

Liebsch, et al. Experimental [Page 6] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

        +--------------+  (1a)AR-AR CARD Request  +----------+
        |   Current    |------------------------->|   CAR    |
        |      AR      |<-------------------------|          |
        +--------------+  (2a)AR-AR CARD Reply    +----------+
            ^      |
            |      |    MN-AR
    MN-AR   |      | CARD Reply(3m)
 CARD Request(2m)  V
         +--------------+
         |    Mobile    |
         |     Node     |<-- CARD Init Trigger
         +--------------+       (1m)
              Figure 1: MN-initiated CARD Protocol Overview
 Figure 1 describes the operation of the MN-AR CARD Request/Reply
 protocol and AR-AR CARD Request/Reply protocol.  On receipt of the
 access points' L2 IDs or the appearance of a CARD initiation trigger
 (1m), the MN may pass on one or more AP L2 IDs to its current AR
 using the MN-AR CARD Request message (2m).  If the MN wants its AR to
 perform capability discovery in addition to reverse address
 translation, this must be indicated in the MN-AR CARD Request message
 by setting the C-flag.  If the C-flag is not set, the AR receiving
 the CARD Request message will perform only reverse address
 translation.  The MN's current AR resolves the L2 ID to the IP
 address of the associated CAR or, if the MN has not attached any L2
 ID message parameters, just reads out all CARs' IP address
 information using the reverse address translation information (L2 ID
 to IP address mapping) from its local CAR table.  The current AR then
 returns to the MN using the MN-AR CARD Reply message (3m), the IP
 addresses of any CARs, each CAR's set of L2 IDs with CANDIDATE
 indicated in the L2 ID sub-option status field, and, if capability
 information has been requested, associated capabilities.
 For the AR-AR CARD Request/Reply protocol, the requesting AR sends a
 CARD Request message to its peer when the CAR table entries time out
 (1a).  The peer returns a CARD Reply message with the requested
 information (2a).

4.1. Conceptual Data Structures

 ARs SHALL maintain an L2-L3 address mapping table (CAR table) that is
 used to resolve L2 IDs of candidate APs to the IP address of the
 associated CAR.  By default, this address-mapping table is configured
 statically for the CARD protocol operation.  Optionally, the CAR
 table MAY be populated dynamically.  Two possible approaches are
 described in Appendices A.1 and A.2.

Liebsch, et al. Experimental [Page 7] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 ARs SHOULD also keep and maintain individual CARs' capabilities in
 the local CAR table, with the associated capability lifetime taken
 into account.  If the lifetime of an individual capability entry has
 expired, the respective capability information is updated.  An AR may
 also initiate capability exchange prior to expiration of the
 capabilities associated with a CAR in the CAR table, thereby
 populating its CAR table.  The AR's CAR table may be implemented
 differently; therefore additional details are not provided here.  ARs
 MUST maintain their own AP-to-AR mappings and capability information
 in their CAR tables, in order to provide newly booted MNs with this
 information so that an MN can obtain the AR's certification path.
 MNs SHOULD maintain discovered address and capability information of
 CARs in a local cache to avoid requesting the same information
 repeatedly and to select an appropriate target AR from the list of
 CARs as quickly as possible when a handover is imminent.

4.2. Mobile Node - Access Router Operation

4.2.1. Mobile Node Operation

 To initiate CARD, an MN sends a CARD Request to its current AR,
 requesting it to resolve the L2 ID of nearby access points to the IP
 address of associated CARs and also obtain capability parameters
 associated with these CARs.  If the requesting MN wants its current
 AR to resolve specific L2 IDs, the MN-AR CARD Request MUST contain
 the CARD protocol-specific L2 ID message parameters.  If the MN wants
 its AR to perform only reverse address translation without appending
 the CARs' capabilities, the MN refrains from setting the C-flag in
 the CARD Request message.  If the MN wants to perform capability
 discovery, the MN MUST set the C-flag in the CARD Request message.
 The CARD Request MAY also contain the Preferences or Requirements
 message parameter, indicating the MN's preferences on capability
 attributes of interest or its requirements on CARs' capability
 attribute-value pairs.
 If the MN appends multiple L2 ID sub-options to a CARD Request, the
 AR MUST assume that each L2 ID is associated with an AP that connects
 to a different CAR.  Since L2 IDs, address information, and
 capability information are transmitted with separate sub-options,
 each sub-option carries a Context-ID, to allow parameters that belong
 together to be matched.  Therefore, the MN MUST assign different
 Context-ID values to the L2 ID sub-options it appends to the CARD
 Request message.  The Status-Code field of the L2 ID sub-option MUST
 always be set to NONE (0x00) by the MN.  The MN MUST set the sequence
 number to a randomly generated value, and the AR MUST include the
 sequence number in all messages of the reply.  If the reply spans
 multiple messages, each message contains the same sequence number.

Liebsch, et al. Experimental [Page 8] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 Upon receipt of the corresponding MN-AR CARD Reply message, the MN
 correlates the CARD Reply with the appropriate CARD Request message
 and then processes all MN-AR CARD Reply message parameters to
 retrieve its CAR's address and capability information.  If the MN is
 unable to correlate the CARD Reply with any previously sent CARD
 Request messages, the MN SHOULD silently discard the reply.  This may
 happen when the MN reboots after sending a CARD Request message to
 the connected AR.
 An MN uses exponential backoff to retransmit the CARD Request in the
 event that a CARD Reply is not received within CARD_REQUEST_RETRY
 seconds.  The retransmitted CARD Request MUST have the same sequence
 number as the original.  With the exception of certification paths,
 which are large by nature, an AR SHOULD attempt to limit the
 information in a CARD Reply to a single message.  Should that be
 impossible, the AR MAY send the reply in multiple messages.  The last
 message of a reply MUST always have the L-flag set in the CARD Reply
 option to indicate that the message is the last for the associated
 sequence number.  An AR retransmitting replies to a CARD Request MUST
 always send the full CARD Reply sequence.  The Trusted Anchor sub-
 option and the Router Certificate sub-option provide a means whereby
 the MN can request specific certificates in a certification path, in
 the event that the CARD Reply carrying a certification path spans
 multiple messages and one of them is lost.  However, a request for
 specific certificates that were not received in the initial CARD
 Reply MUST be treated as a new request by the MN and MUST use a
 different sequence number.
 Processing the Context-ID of Address sub-options allows the MN to
 assign the resolved IP address of a specific CAR to an L2 ID.
 In some cases, an L2 ID parameter is present in a CARD Reply message.
 The Status-Code field in the L2 ID parameter indicates one of the
 following reasons for its being sent toward the MN.
 RESOLVER ERROR Status-Code indication:
    If the MN's current AR could not resolve a particular L2 ID, this
    status code is returned to the MN.
 MATCH Status-Code indication:
    If an L2 ID is encountered that shares a CAR with a previously
    resolved L2 ID, the AR returns MATCH to the MN.  This status code
    indicates that the Context-ID of this particular L2 ID sub-option
    has been set to the Context-ID of the associated CAR's Address and
    Capability Container sub-option, which is sent with this CARD
    Reply message.  This approach avoids sending the same CAR's
    address and capability information multiple times with the same
    CARD Reply message in case two or more L2 IDs resolve to the same

Liebsch, et al. Experimental [Page 9] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

    CAR.  An MN uses the Context-ID received in the L2 ID sub-option
    as the key to find the serving CAR of the given AP from the
    content of the received CARD Reply message.
 CANDIDATE Status-Code indication:
    If the MN does not append any L2 ID to the CARD Request, the AR
    sends back the L2 ID and address information of all CARs.  Because
    the received parameters' Context-IDs cannot be correlated with an
    L2 ID's Context-ID of a previously sent request, the AR chooses
    values for the Context-ID and marks these candidate L2 IDs with
    CANDIDATE in the status code of the distributed L2 IDs.  However,
    individual values of L2 IDs' Context-ID allow the MN to assign a
    particular L2 ID to the associated Address and the possibly
    received Capability Container sub-option.
    As described in Section 4.5, an MN can use CARD when it initially
    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

Liebsch, et al. Experimental [Page 10] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 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

Liebsch, et al. Experimental [Page 11] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 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

Liebsch, et al. Experimental [Page 12] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 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

Liebsch, et al. Experimental [Page 13] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 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.

Liebsch, et al. Experimental [Page 14] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

    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.

Liebsch, et al. Experimental [Page 15] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

    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-

Liebsch, et al. Experimental [Page 16] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

                   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.

Liebsch, et al. Experimental [Page 17] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

    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
                               message to perform reverse address
                               translation.  This flag is set if CARD
                               protocol messages are piggybacked with
                               a protocol that performs reverse
                               address translation.  For details,
                               refer to Section 4.4 of this document.

Liebsch, et al. Experimental [Page 18] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

                      T-flag:  Indicates that the requesting entity is
                               interested in obtaining all
                               certificates from the responder.  This
                               flag is only valid on the AR-AR
                               interface.
             The flag combination A=1 and C=0 is invalid, and the flag
             T=1 is invalid on the MN-AR interface.  The AR MUST
             discard an invalid message and log an appropriate error
             message.
    Reserved:
             Initialized to zero, ignored on receipt.
    Sequence Number:
             Allows requests to be correlated with replies.
 Valid Sub-Options:
  1. L2 ID sub-option
  2. Preferences sub-option
  3. Requirements sub-option
  4. Trusted Anchor sub-option
 To ensure that requirements on boundary alignment are met, individual
 sub-options MUST meet the 64-bit boundary alignment requirements
 respectively.  This will ensure that the entire CARD Request option
 meets the 8n alignment constraint.

5.1.2.2. CARD Reply 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|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.

Liebsch, et al. Experimental [Page 19] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

    Vers.:   3-bit version code.  For this specification, Vers.=1.
             Flags:   P-flag:  Indicates the CARD-protocol message
                               piggybacking capability of the CARD
                               Reply message sender.  A description
                               for proper use of this flag can be
                               found in Section 4.4 of this document.
                      U-flag:  Indicates an unsolicited CARD Reply.
                               This flag is only valid on the AR-AR
                               interface.
                      L-flag:  Set if this message is the last message
                               in a multiple ICMP message reply.  This
                               flag is 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.
    Reserved:
             Initialized to zero, ignored on receipt.
    Sequence Number:
             Allows requests to be correlated with replies.
 Valid Sub-Options:
  1. L2 ID sub-option
  2. Capability Container sub-option
  3. Address sub-option
  4. Router Certificate sub-option
 To ensure requirements on boundary alignment are met, individual
 sub-options MUST meet 64-bit boundary alignment requirements
 respectively.  This will ensure that the entire CARD Request option
 meets the 8n alignment constraint.

5.1.3. Sub-Options Format

 All sub-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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Sub-Option Type|Sub-Option Len |       Sub-Option Data . . .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Liebsch, et al. Experimental [Page 20] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 Sub-Option Type:  8-bit identifier of the type of option.  The
                   sub-options defined in this document are listed
                   in the table below.  The table also indicates
                   on which interfaces the sub-option is valid.
        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           x
 Sub-Option-Length: 8-bit unsigned integer indicating the length of
                    the sub-option, including the sub-option type and
                    sub-option length fields.  Sub-option lengths are
                    in units of 8 octets, aligned on a 64-bit
                    boundary.  Sub-options that are shorter are padded
                    with null octets; the extent of the padding is
                    determined by the sub-option contents.

5.1.3.1. L2 ID Sub-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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Sub-Option Type|Sub-Option Len |   Context-ID  |  Status Code  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    L2-Type                    |     L2 ID . . .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
 Sub-Option Type:
                0x01
 Sub-Option Length:
                Length of the sub-option.
 Context-ID:    Associates the L2 ID, IP address and other parameters
                that belong to the same AR IP address but are encoded
                in separate sub-options.

Liebsch, et al. Experimental [Page 21] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 Status Code:   This field allows ARs to inform a requesting entity
                about processing results for a particular L2 ID.  The
                L2 ID sub-option MUST be sent back to the requesting
                entity with a CARD Reply message.
                The following status codes are specified:
             0x00:    NONE - This value MUST be set when the L2 ID is
                      included in a CARD Request.
             0x01:    CANDIDATE - MUST be set in a CARD Reply when a
                      L2 ID sub-option is included with information
                      about candidate APs' L2 IDs.  Candidate L2 IDs
                      are sent if the CARD Request did not include a
                      specific L2 ID for resolution.  If CANDIDATE is
                      set, the AR MUST set the Context-ID field of
                      individual parameters to a value that allows
                      associated L2 ID, address, and capability
                      information to be matched on the receiver side.
             0x02:    MATCH - MUST be set in the CARD Reply to
                      identify that this L2 ID matches previously
                      resolved CAR information for a different L2 ID.
                      If MATCH is set, the AR sets the Context-ID in
                      the L2-ID sub-option to identify the matching
                      previously resolved L2 ID.
             0x03:    RESOLVER ERROR - MUST be set in the CARD Reply
                      if the L2 ID cannot be resolved.  The AR sets
                      this value for the Status Code in the returned
                      L2 ID sub-option.
 L2 type:       Indicates the interface type.  Allocated by IANA
                [Ke04].
 L2 ID:         The variable length Layer-2 identifier of an
                individual CAR's access point.  The length without
                padding is determined by the L2 type.

5.1.3.2. Preferences Sub-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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Sub-Option Type|Sub-Option Len |         Preferences
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Liebsch, et al. Experimental [Page 22] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 Sub-Option Type:
                0x04
 Sub-Option Length:
                Length of the sub-option.
 Preferences:   List of capability attribute values (see Section
                5.1.4).
 Only ATTRIBUTE (AVP Code; see Section 5.1.4) fields MUST be present
 and set for individual capabilities, which are of interest to the
 requesting entity.  The LIFETIME and VALUE (Data) indicator will not
 be processed and can be omitted.  The AVP LENGTH indicator is also
 not present, as the preferences are indicated only with a list of
 16-bit encoded ATTRIBUTE fields.  If 64-bit boundary alignment
 requirements cannot be met with the list of ATTRIBUTE values, padding
 the missing 16-bit MUST be done with an ATTRIBUTE value of 0x0000.
 An ATTRIBUTE code of 0x0 is reserved so that the end of the ATTRIBUTE
 code list can be determined when an ATTRIBUTE value of 0x0 is read.
 The use of the Preferences sub-option is optional and is for
 optimization purposes.

5.1.3.3. Requirements Sub-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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |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)
 AVPs MUST be encoded according to the rule described in Section
 5.1.4.  Both the ATTRIBUTE (AVP Code) and VALUE (Data) fields MUST be
 present and set appropriately.  The end of the Requirements list can
 be determined when an ATTRIBUTE value of 0x0 is read.
 The use of the Requirements sub-option is optional and is for
 optimization purposes.

Liebsch, et al. Experimental [Page 23] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

5.1.3.4. Capability Container Sub-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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |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:    Associates the L2 ID, IP address, and other parameters
                that belong to the same AR IP address but are encoded
                in separate sub-options.
 Flags:         P-flag:  Indicates piggybacking capability of the CAR
                         whose capabilities are conveyed in this
                         Capability Container.  This flag allows an MN
                         to know after a CARD process whether a
                         selected new AR can perform piggybacking.
 Reserved:      Initialized to zero, ignored on receipt.
 AVPs:          AVPs are a method of encapsulating capability
                information relevant for the CARD protocol.  See
                Section 5.1.4 for the AVP encoding rule and list
                parsing.

5.1.3.5. Address Sub-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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Sub-Option Type|Sub-Option Len |  Context-ID   | Address Type  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Address . . .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -
 Sub-Option Type:
                0x02

Liebsch, et al. Experimental [Page 24] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 Sub-Option Length:
                Length of the sub-option.  For IPv4, the length is 1
                (8 octets); for IPv6 the length is 3 (24 octets).
 Context-ID:    Associates the L2 ID, IP address, and other parameters
                that belong to the same AR IP address but are encoded
                in separate sub-options.
 Address Type:  Indicates the type of the address.
                                     0x01  IPv4
                                     0x02  IPv6
 Address:       The Candidate Access Router's IP address.

5.1.3.6. Trusted Anchor Sub-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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |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, ignored on receipt.
 Component:     A 2 octet unsigned integer field set to 65,535 if the
                sender desires to retrieve all the certificates in the
                certification path.  Otherwise, it is set to the
                component identifier corresponding to the certificate
                that the receiver wants to retrieve.
 Trusted Anchor Name:
                DER encoding for the X.501 name of certification path
                component(see [Arkko04] for more detail on
                certification path component name encoding).
 A CARD Request message containing Trusted Anchor sub-options MUST NOT
 contain any other sub-options, except for a single L2 ID sub-option
 identifying the AP of interest.

Liebsch, et al. Experimental [Page 25] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 Trusted anchor sub-options SHOULD be retransmitted for individual
 components not received within CARD_REQUEST_RETRY seconds, rather
 than retransmitting a request for the whole list.  Subsequent
 retransmissions SHOULD take into account any received options and
 only request those that have not been received.

5.1.3.7. Router Certificate Sub-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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |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:    Associates the L2 ID, IP address and other parameters
                that belong to the same AR IP address but are encoded
                in separate sub-options.
 Reserved:      Initialized to zero, ignored on receipt.
 All Components:
                2 octet unsigned integer giving the total number of
                certificates in the certification path.
 Component:     2 octet unsigned integer giving the location of this
                certificate in the certification path.
 Certificate:   Variable-length field containing the X.509v3 router
                certificate encoded in ASN.1 (see [Arkko04] for more
                detail on a certificate profile that includes
                encoding).

Liebsch, et al. Experimental [Page 26] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 Padding:       Variable-length field making the option length a
                multiple of 8, beginning after the ASN.1 encoding of
                the certificate and continuing to the end of the
                option, as specified by the Length field.
 A CARD Reply containing a Router Certificate sub-option MUST NOT
 include more than one such sub-option, and the CARD Reply MUST
 contain the matching L2 ID sub-option and router Address sub-option
 for the router possessing the chain with the Context-ID field set to
 a nonzero value, and with no other sub-options.  Any other sub-
 options included in a CARD Reply SHOULD be ignored.  If the reply
 spans 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 that in the L2 ID and
 Address sub-options.  The replying AR SHOULD order the returned
 certification path so that the certificate immediately after the
 trust anchor in the path is the first certificate sent, in order to
 allow immediate verification.  The trust anchor certificate itself
 SHOULD NOT be sent.

5.1.4. Capability AVP Encoding Rule

  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.  The AVP Code
                0x0000 is reserved and MUST NOT be assigned to a
                capability.
 AVP Length:    The 2 octet AVP length field indicates the number of
                octets in this AVP, including the AVP Code, AVP
                Length, Reserved, Lifetime, and Data fields.
 Reserved:      Initialized to zero, ignored on receipt.
 Lifetime:      Specifies the lifetime of the encoded capability in
                seconds.  In the case of a static capability, the
                Lifetime field MUST be set to the maximum value
                (0xffff), which indicates that the lifetime of this
                capability parameter never expires.  A lifetime value
                of 0x0000 deletes a capability entry.

Liebsch, et al. Experimental [Page 27] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 Data:          This variable-length field has the Value of the
                capability attribute encoded.
 Because an AVP Code of 0x0 is reserved, it can be used by the sub-
 option list parsing to determine when the end of a list of
 Capabilities has been reached and 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.

5.2. CARD Inter-Access Router Messages

5.2.1. AR-AR Transport

 Because the types of access networks in which CARD might be useful
 are not currently deployed or, if they have been deployed, have not
 been extensively measured, it is difficult to know whether congestion
 will be a problem for inter-router CARD.  Part of the research task
 in preparing CARD for consideration as a candidate for possible
 standardization is to quantify this issue.  However, in order to
 avoid potential interference with production applications (should a
 prototype CARD deployment involve running over the public Internet),
 it seems prudent to recommend a default transport protocol 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.  SCTP
 also supports many advanced and complex features, such as multiple
 streams and multiple IP addresses for failover, that are not
 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.  CARD messages
 on the inter-router interface consist of just the CARD Request or
 CARD Reply options.  The User Data part of each SCTP message contains
 the CARD option for the message type.  For instance, a CARD Reply
 message is constructed by including the CARD Reply option and all the
 appropriate sub-options within the User Data part of an SCTP message.

Liebsch, et al. Experimental [Page 28] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 A single stream is used for CARD with in-sequence delivery of SCTP
 messages.  Each message, unless fragmented, corresponds to a single
 CARD query or response.  Unsolicited CARD Reply messages can also be
 sent to peers to notify them of changes in network configuration or
 capabilities.  A single stream provides simplicity.  Use of multiple
 streams to prevent head-of-line blocking is for future study.  Since
 timeliness is not an issue with inter-router CARD, and since there
 being more than one CARD transaction between two routers active at
 any one time is unlikely, having ordered delivery simplifies the
 implementation.  The Payload Protocol Identifier in the SCTP header
 is 'CARD'.  CARD uses the Seamoby SCTP port number [Ke04].
 The format of 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.

Liebsch, et al. Experimental [Page 29] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 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 is not in its
 CAR table MUST NOT solicit the AR but rather MUST wait until the AR
 sends an unsolicited CARD Reply advertising the AR's information.  An
 AR that is starting up MUST send unsolicited CARD Replies to all its
 CARs to make sure that their CAR tables are properly populated.
 The frequency of unsolicited CARD Reply messages MUST be strictly
 limited to CARD_MIN_UPDATE_INTERVAL, in order to avoid overwhelming
 CARs with traffic.  ARs are free to discard messages that arrive more
 frequently.
 If a CARD deployment will never run over the public Internet, and if
 it is known that congestion is not 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
 accommodate good Internet transport protocol engineering practices,
 such as using retransmits with exponential backoff.  In addition,
 whether SCTP is an appropriate transport protocol for all inter-
 router CARD operations is an open research question.  Investigation
 of this issue (for example, to determine whether a lighter-weight
 protocol might be more appropriate 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 allows
 the receiving AR to determine whether the information has already
 been received.
 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 those 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.
 Additionally, an AR can set the T flag in the CARD Request header in

Liebsch, et al. Experimental [Page 30] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 order to obtain the certificates for the CAR.  The description of
 sub-options in Section 5.1.3 includes information on what flag
 settings are prohibited on the AR-AR interface.

6. Security Considerations

6.1. Veracity of CARD Information

 The veracity of the CARD protocol depends on the ability of an AR to
 obtain accurate information about geographically neighboring ARs, and
 to provide accurate information about its own APs and capabilities to
 other ARs.  The CARD protocol described in the body of this document
 does not contain any support for determining the AR-to-AP mapping or
 capabilities, either for a specific AR or for a CAR.  Therefore,
 methods for determining 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 discuss relevant security considerations.
 Alternatively, this information could be statically configured into
 the AR.

6.2. Security Association between AR and AR

 CARD contains support allowing ARs to exchange capability
 information.  If this protocol is not protected from modification, a
 malicious attacker can modify the information.  Also, if the
 information is delivered in plain text, a third party can read it.
 To prevent 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.

Liebsch, et al. Experimental [Page 31] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 If CARD is used to exchange information between different
 administrative domains, additional security policy issues may apply.
 Such 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 establishing an IPSec security
 association between the MN and AR is likely to be a performance
 issue, IKE is not an appropriate mechanism for setting up the
 security association.  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 provide the MN with CARD information that would lead the MN to
 handover to a bogus router, which could steal traffic or propagate a
 denial of service attack on the MN.  The asymmetry of the
 authentication requirement is the same as that 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,
 network operators may want to hide information about operator-
 specific capabilities for business reasons.  The base CARD protocol
 contains no support for such cases.  However, should such a case
 arise in the future, an AVP for an encrypted capability can be
 defined at that time.

6.4. Router Certificate Exchange

 Because SEND is only available in IPv6, the procedures for obtaining
 certificates differ depending on whether CARD is used with IPv4 or
 IPv6.  In IPv6, when the MN receives a CARD reply with signature from
 an AR for which it does not have a certificate, it SHOULD use SEND
 DCS/DCA to obtain 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 to
 allow verification of the AR certificates.  An MN may not necessarily

Liebsch, et al. Experimental [Page 32] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 need to use Cryptographically Generated Addresses (CGAs) with CARD,
 so CGA support is OPTIONAL for CARD.  A certificate profile for ARs
 is described in the SEND specification [Arkko04].
 In IPv4, there is no DCS/DCA message for obtaining the certificate.
 If the MN does not have a certificate for the AR, the MN sends a CARD
 Request message containing the L2 ID of its current AP and one
 Trusted Anchor sub-option (Section 5.1.3.6) for each shared trusted
 anchor for which the MN has a certificate, to obtain the
 certification path for the current AR.  The Component field of the
 Trusted Anchor sub-option is set to 65535 to indicate that the entire
 certification path is needed.  No other options should be included in
 the request.  The AR replies by sending a CARD Reply containing the
 L2 ID sub-option sent in the request, an Address sub-option for
 itself, and a Router Certificate sub-option (Section 5.1.3.7)
 containing one certificate in its certification path that matches one
 of the requested trust anchors, and no other sub-options, setting the
 Context-ID of all sub-options to match.  The All Components field is
 set to the path length, and the Component field is set to the number
 of this component 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 other certificates in
 separate ICMP messages, due to the limitation on ICMP message length,
 with the same Context-ID set on each Route Certificate sub-option,
 and with the Component field properly set.  The router SHOULD NOT
 send the trusted anchor's certificate and SHOULD send certificates in
 order from the certificate after the trusted anchor.  If the trusted
 anchor option does not match any certificate, the AR returns the
 Trusted Anchor sub-options in the reply.  The MN SHOULD immediately
 conduct a Certificate Revocation List (CRL) check on any certificates
 obtained through CARD certificate exchange, to make sure that the
 certificates are still valid.
 Certification paths for CARs may be fetched in advance of handover by
 requesting them as part of the CARD protocol.  In that case, the MN
 includes Trusted Anchor sub-options in the CARD request along with
 the L2 ID sub-option for the AP for which the CAR certificate is
 desired, and the AR replies as above, except that the L2 ID, address,
 and certificates are for the CAR instead of for the AR itself.  This
 allows the MN to 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.

Liebsch, et al. Experimental [Page 33] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

6.5. DoS Attack

 An AR can be overwhelmed with CARD Request messages.  The AR SHOULD
 implement a rate-limiting policy so that it does not send or process
 more than a certain number of messages per period.  The following is
 a suggested rate limiting policy.  If the number of CARD messages
 exceeds CARD_REQUEST_RATE, the AR SHOULD begin to drop messages
 randomly until the rate is reduced.  MNs SHOULD avoid sending
 messages more frequently than CARD_REQUEST_RATE.  ARs SHOULD also
 avoid sending unsolicited CARD Replies or CARD Requests more
 frequently than CARD_MIN_UPDATE_INTERVAL, but, in this case, the
 existence of an IPsec security association ensures that messages from
 unknown entities will be discarded immediately during IPsec
 processing.
 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 the attack is without serious consequence because the MN
 ignores the reply in any case.

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.

Liebsch, et al. Experimental [Page 34] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 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.

Liebsch, et al. Experimental [Page 35] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 [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.

Liebsch, et al. Experimental [Page 36] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

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

 The centralized approach performs CARD over the MN-AR interface as
 described in Section 4 of this document.  Additionally, the
 centralized approach introduces a new entity, the CARD server, to
 assist the current AR in performing reverse address translation.  The
 centralized approach requires that neighboring ARs register with the
 CARD server to populate the reverse address translation table.  The
 registration of AR addresses with the CARD server is performed prior
 to initiation of any reverse address translation request.
 Figure A.1 illustrates a typical scenario of the centralized CARD
 operation.  In this example, ARs have registered their address
 information with a CARD server in advance.  When an MN discovers the
 L2 ID of APs during L2 scanning, it passes one or more L2 IDs to its
 current AR, and the AR resolves them to the IP address of the AR.
 For this, the AR first checks whether the mapping information is
 locally available in its CAR table.  If it is not, the MN's current
 AR queries a CARD server with the L2 ID.  In response, the CARD
 server returns the IP address of the CAR to the current AR.  Then,
 the current AR directly contacts the respective CAR and performs
 capability discovery with it.  The current AR then passes the IP
 address of the CAR and associated capabilities to the MN.  The
 current AR then stores the resolved IP address within its local CAR
 table.  The centralized CARD protocol operation introduces additional
 signaling messages, which are exchanged between the MN's current AR
 and the CARD server.  The signaling messages between an AR and the
 CARD server function are shown with the preceding identifier "AR-
 Server", referring to the associated interface.
 An initial idea of performing reverse address translation using a
 centralized server is described in [Funa02].

Liebsch, et al. Experimental [Page 37] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

                                 +----------+
                   +------------>|   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 Mapping

Appendix A.2. Decentralized Approach Using Mobile Terminals'

             Handover
 This approach performs CARD over the MN-AR interface as described in
 Section 4.  However, it employs one additional message, called the
 Router Identity message, over the MN-AR interface to enable ARs to
 learn about the reverse address translation tables of their
 neighboring ARs, without being dependent on any centralized server.
 In this approach, CAR identities in the CAR table of an AR are
 maintained as soft state.  The entries for CARs are removed from the
 CAR table if they are not refreshed before the timeout period expires
 and are created or refreshed according to the following mechanism.
 The key idea behind the decentralized approach is to bootstrap and
 maintain the association between two ARs as neighbors of each other
 using the actual handover of MNs occurring between them as input.
 The first handover between any two neighboring ARs serves as the
 bootstrap handover to invoke the discovery procedure, and the
 subsequent handover serves to refresh the association between the
 neighboring ARs.  After the bootstrap handover, the MNs can perform

Liebsch, et al. Experimental [Page 38] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 CARD and thus seamless handover using the CAR information.  This idea
 was presented in [ShGi00] and [Tros03].
 Maintenance of the CAR table is done by using an additional option
 for the CARD protocol operation performed between an MN and its
 current AR.  This message serves as Router Identity message.
 Upon the completion of an inter-AR handover, the MN SHOULD send a
 Router Identity message to its current AR.  This message contains the
 identity (IP address) of the previous AR (pAR), and can be sent 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
 enables the MN's current AR to learn that the pAR (still) has an AP
 whose coverage overlaps with one of the APs of the current AR, and
 vice versa.  With this information, the MN's current AR can create or
 refresh an entry for the pAR as its neighbor.  If handover is no
 longer possible between two ARs, the associated entries eventually
 timeout and are removed from each AR's CAR table.
 Prior to trusting the MN's report, however, the current AR may
 perform a number of checks to ensure the validity of the received
 information.  One simple method is to verify the accuracy of the
 Router Identity message by sending an AR-AR CARD Request message to
 the pAR.  The AR-AR CARD Request includes the identity of the MN.
 Upon receiving this message, the pAR verifies that the MN was indeed
 attached to it during a reasonable past interval and responds to the
 current AR.  In this way, each handover of a MN results in a bi-
 directional discovery process between the two participating ARs.
 Upon receiving a positive verification response, the current AR
 creates or refreshes, as applicable, the entry for the pAR in its
 local CAR table.  In the former case, the current AR and the pAR
 exchange capabilities using the AR-AR CARD Request and AR-AR CARD
 Reply protocol messages.  When a new entry is created, the ARs MUST
 exchange their reverse address translation tables.  They may exchange
 other capabilities at this time or may defer exchange to a later time
 when some MN undergoing handover between them performs CARD as
 described in Section 4.  In the latter (refresh) case, ARs may
 exchange capabilities or defer exchanges until a later time when
 another MN undergoes handover.
 Finally, note that in a handover-based protocol, a first handover
 between a pAR and an MN's current AR cannot use CARD, as this
 handover bootstraps the CAR table.  However, in the long term, such a
 handover will only amount to a small fraction of total successful
 handover between the two ARs.  Also, if the MN engaging in such a
 first handover is running a non-delay sensitive application at the
 time of handover, the user may not even realize its impact.

Liebsch, et al. Experimental [Page 39] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

Appendix B. Application Scenarios

 This section provides two examples of application scenarios for CARD
 protocol operation.  One scenario describes a CARD protocol operation
 in a Mobile IPv6 (MIPv6) network, providing access to the
 infrastructure via wireless LAN Access Points and associated Access
 Routers.  A second scenario describes CARD protocol operation in a
 Mobile IPv6-enabled network, which has enhanced support for fast
 handover integrated (Fast Mobile IPv6), also providing wireless LAN
 access to the infrastructure.
 This application scenario assumes a moving MN having access to the
 infrastructure through wireless LAN (IEEE802.11) APs.  Mobility
 management is performed using the Mobile IPv6 protocol.  The
 following figure illustrates the assumed access network design.

Appendix B.1. CARD Operation in a Mobile IPv6-Enabled Wireless LAN

             Network
  1. —————————-

/ \ +—-+

                    |           NETWORK           |---| HA |
                    \                             /   +----+
                     -----------------------------
                      |                         |
                   +-----+                   +-----+
                   | AR1 |---------+         | AR2 |
                   +-----+         |         +-----+
                      |  subnet 1  |            |subnet 2
                   +-----+      +-----+      +-----+
                   | AP1 |      | AP2 |      | AP3 |
                   +-----+      +-----+      +-----+
                      ^            ^            ^
                       \
                        \
                         \
                          v
                       +-----+
                       | MN  | - - ->>>- - - ->>>
                       +-----+
                 Figure B.1: Assumed Network Topology
 A Mobile IPv6 Home Agent (HA) maintains location information for the
 MN in its binding cache.  In Figure B.1, the MN holds a care-of
 address for the subnet 1, supported by AR1.  As the MN moves, the
 MN's current environment offers two further wireless LAN APs with
 increasing link-quality as candidate APs for a handover.  To

Liebsch, et al. Experimental [Page 40] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 facilitate decision making, parameters associated with ARs are taken
 into account during the decision process.  The AR-related parameters
 can be, for example, available QoS resources or the type of access
 technologies supported from an AR.  To learn about these candidate
 ARs' capabilities and associated IP address information, the MN
 performs CARD.  This requires retrieving information about candidate
 APs' L2 IDs.  Furthermore, associated link-quality parameters are
 retrieved to ascertain whether approaching APs are eligible
 candidates for a handover.  If AP2 and AP3 are suitable candidate
 APs, the MN encapsulates both L2 IDs (AP2 and AP3) into a CARD
 Request message, using the L2 ID sub-option, and sends the message to
 its current AR (AR1).
 AR1 resolves each L2 ID listed in L2 ID options to the associated IP
 address of the respective CAR, making use of its local CAR table.
 According to the environment illustrated in Figure B.1, the
 associated AR IP address of the candidate AP2 will be the same as the
 MN is currently attached to, which is AR1.  The corresponding IP
 address of the candidate AR, to which AP3 is connected, is the
 address of AR2.  IP addresses of the MN's CARs are now known to AR1,
 which retrieves the CARs' capabilities from the CAR table.  Assuming
 that it has valid entries for respective capability parameters to
 refresh dynamic capabilities, whose associated lifetimes in AR1's CAR
 table have expired, AR1 performs Inter-AR CARD for capability
 discovery.  Since capability information for AR1 is known to AR1, a
 respective Inter-AR CARD Request is sent only to AR2.  In response,
 AR2 sends a CARD Reply message back to AR1, encapsulating the
 requested capability parameters with the signaling message in a
 Capability Container sub-option.
 Next, AR1 sends its own capabilities and the dynamically discovered
 ones of AR2 back to the MN via a CARD Reply message.  Furthermore,
 AR1 stores the capability parameters of AR2 with the associated
 lifetimes in its local CAR table.
 Upon receipt of the CARD Reply message, the MN performs target AR
 selection, taking AR1's and AR2's capability parameters and
 associated APs' link-quality parameters into account.  If the
 selected AP is AP2, no IP handover needs to be performed.  If AP3 and
 the associated AR2 are selected, the MN needs to perform an IP
 handover according to the Mobile IPv6 protocol operation.

Liebsch, et al. Experimental [Page 41] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 Figure B.2 illustrates the signaling flow of the previously described
 application scenario of CARD within 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

Liebsch, et al. Experimental [Page 42] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

Appendix B.2. CARD Operation in a Fast Mobile IPv6 Network

 This application scenario assumes that ARs can perform the fast
 handover protocol sequence for Mobile IPv6 [Kood03].  The MN scans
 for new APs for handover, similar to Figure B.1.  To discover the ARs
 (CARs), the MN attaches a MN-AR CARD Request option to the ICMP-type
 Fast Mobile IPv6 RtSolPr message, which is sent to the MN's current
 AR (pAR, previous AR).
 Candidate APs' L2 IDs are encapsulated using the CARD protocol's L2
 ID sub-options, which allow the MN to send multiple L2 IDs of
 candidate APs to its current AR.  (This potentially replaces the "New
 Attachment Point Link-Layer Address" option of the Fast Mobile IPv6
 protocol.)
 The pAR resolves the received list of candidate APs' L2 IDs to the IP
 addresses of associated CARs.  The pAR checks its local CAR table to
 retrieve information about the CARs' capabilities.  If any table
 entries have expired, the pAR acquires this CAR's capabilities by
 sending an AR-AR CARD Request to the respective CAR.  The CAR replies
 with an AR-AR CARD Reply message, encapsulating all capabilities in a
 Capability Container sub-option and attaching them to the CARD Reply
 option.  On receipt of the CARs' capability information, the pAR
 updates its local CAR table and forwards the address and capability
 information to the MN by attaching a MN-AR CARD Reply option to the
 Fast Mobile IPv6 PrRtAdv message.  When the MN's handover is
 imminent, the MN selects its new AR and the associated new AP from
 the discovered list of CARs.  According to the Fast Mobile IPv6
 protocol, the MN notifies the pAR of the selected new AR with the
 Fast Binding Update (F-BU) message, allowing the pAR to perform a
 fast handover according to the Fast Mobile IPv6 protocol.
 Optionally, the pAR could perform selection of an appropriate new AR
 on behalf of the MN after the pAR has the MN's CARs' addresses and
 associated capabilities available.  The MN must send its requirements
 for the selection process to its pAR together with the MN-AR CARD
 Request message After the pAR has selected the MN's new AR, the
 address and associated capabilities of the chosen new AR are sent to
 the MN with the CARD Reply option in the Fast Mobile IPv6 PrRtAdv
 message.

Liebsch, et al. Experimental [Page 43] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

 Figure B.3 illustrates how CARD protocol messages and functions work
 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.

Liebsch, et al. Experimental [Page 44] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

Authors' Addresses

 Hemant Chaskar
 AirTight Networks
 339 N. Bernardo Avenue
 Mountain View, CA 94043, USA
 EMail: hemant.chaskar@airtightnetworks.net
 Daichi 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.jp
 Marco Liebsch
 NEC Network Laboratories
 Kurfuersten-Anlage 36,
 69115 Heidelberg, Germany
 Phone: +49 6221-90511-46
 EMail: marco.liebsch@netlab.nec.de
 Eunsoo Shim
 Panasonic Digital Networking Laboratory
 Panasonic Corporation
 Two Research Way
 Princeton, NJ 08540
 Phone: +1-609-734-7354
 EMail: eunsoo@research.panasonic.com
 Ajoy Singh
 Motorola Inc
 2G11, 1501 West Shure Dr.
 Arlington Heights, IL 60004, USA
 Phone: +1 847-632-6941
 EMail: asingh1@email.mot.com

Liebsch, et al. Experimental [Page 45] RFC 4066 Candidate Access Router Discovery (CARD) July 2005

Full Copyright Statement

 Copyright (C) The Internet Society (2005).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 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.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Liebsch, et al. Experimental [Page 46]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4066.txt · Last modified: 2005/07/06 23:39 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki