IETF Seamoby Working Group                             CARD Design Team
Internet Draft                                            Marco Liebsch
                                                             Ajoy Singh
                                                              (Editors)
                                                         Hemant Chaskar
                                                          Daichi Funato
draft-ietf-seamoby-card-protocol-01.txt
Expires: September 2003                                      March 2003


                     Candidate Access Router Discovery


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   To view the list of Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.


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 of candidate ARs (CARs) for handover, along with their
   capabilities, prior to the initiation of the IP-layer handover.
   Depending upon the mode of operation, the current AR may or may not
   be involved in the CAR discovery process. The act of discovery of
   CARs has two aspects to it: Identifying the IP addresses of the CARs
   and finding the capabilities of those CARs. This process is called
   "candidate access router discovery" (CARD). At the time of IP-layer
   handover, that CAR, whose capabilities are a good match to the
   preferences of the MN, may be chosen as the target AR (TAR) for
   handover. This draft describes a solution to perform CARD.



CARD Design Team       Expires û September 2003               [Page 1]


Internet-Draft     Candidate Access Router Discovery        March 2003


TABLE OF CONTENTS


1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.  CARD Protocol Functions . . . . . . . . . . . . . . . . . . . . 4
    3.1 Reverse Address Translation . . . . . . . . . . . . . . . . 4
    3.2 Discovery of CAR Capabilities . . . . . . . . . . . . . . . 5
4.  CARD Protocol Operation . . . . . . . . . . . . . . . . . . . . 6
    4.1 MN-Orchestrated CARD. . . . . . . . . . . . . . . . . . . . 6
    4.2 Network-Assisted CARD . . . . . . . . . . . . . . . . . . . 7
5.  Protocol Messages . . . . . . . . . . . . . . . . . . . . . . .12
    5.1 CARD Messages for the interface MN - AR . . . . . . . . . .12
      5.1.1 CARD Main Header Format.  . . . . . . . . . . . . . . .12
      5.1.2 CARD Options Format . . . . . . . . . . . . . . . . . .14
         5.1.2.1 CARD Request Option .. . . . . . . . . . . . . . .15
         5.1.2.2 CARD Reply Option .. . . . . . . . . . . . . . . .15
      5.1.3 Sub-Options Format .. . . . . . . . . . . . . . . . . .16
         5.1.3.1 L2-ID Sub-Option . . . . . . . . . . . . . . . . .17
         5.1.3.2 Preferences Sub-Option . . . . . . . . . . . . . .17
         5.1.3.3 Requirements Sub-Option .. . . . . . . . . . . . .18
         5.1.3.4 Capability Container Sub-Option. . . . . . . . . .18
         5.1.3.5 Address Sub-Option . . . . . . . . . . . . . . . .19
      5.1.4 CARD AVP encoding . . . . . . . . . . . . . . . . . . .20
    5.2 CARD Messages for the interface between ARs (AR - AR) . . .21
      5.2.1 Protocol transport (AR-AR). . . . . . . . . . . . . . .21
      5.2.2 Protocol main header. . . . . . . . . . . . . . . . . .21
      5.2.3 Protocol payload types. . . . . . . . . . . . . . . . .22
    5.3 CARD Messages for the interface between an
       AR and the CARD server . . . . . . . . . . . . . . . . . . .22
      5.3.1 Protocol transport (AR-Server function) . . . . . . . .22
      5.3.2 Protocol main header. . . . . . . . . . . . . . . . . .22
      5.3.3 Protocol payload types. . . . . . . . . . . . . . . . .23
    5.4 Overview on sub-options'/payload types' usage . . . . . . .24
6.  Security Considerations . . . . . . . . . . . . . . . . . . . .24
    6.1 Security Associations . . . . . . . . . . . . . . . . . . .24
    6.2 DoS Attack  . . . . . . . . . . . . . . . . . . . . . . . .24
    6.3 CAR Cache Contamination . . . . . . . . . . . . . . . . . .25
7.  IANA considerations . . . . . . . . . . . . . . . . . . . . . .26
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . .26
9.  Authors' addresses  . . . . . . . . . . . . . . . . . . . . . .27
10. IPR Statements. . . . . . . . . . . . . . . . . . . . . . . . .27
11. Copyright Notice  . . . . . . . . . . . . . . . . . . . . . . .28
12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . .28







CARD Design Team       Expires û September 2003               [Page 2]


Internet-Draft     Candidate Access Router Discovery        March 2003

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [1].


1. Introduction

   IP mobility protocols enable mobile nodes (MNs) to execute IP-level
   handover between access routers (ARs). CAR discovery (CARD) enables
   acquiring information about the ARs that are candidates (CARs) for
   the MN's handover.

   In future wireless networks, there will be cases when a MN has a
   choice of performing IP-level handover to different CARs. The MN
   would then choose one of them as a target access router (TAR) for
   handover, based on a match between a MN's requirements and CARs'
   capabilities. The MN requires some means of obtaining information
   about the CARs so that the best decision about the TAR can be made.
   The CARD protocol enables this.

   The problem statement and requirements for CARD are discussed in [2]
   and [3] respectively. In this draft, we describe a solution to
   perform CARD. We begin by describing two main functions of the CARD
   protocol. Then, we describe two modes of protocol operation that we
   think cover most of the important handover scenarios. Finally, we
   describe the messages and protocol operation of MN-AR, AR-AR and AR-
   server interfaces of the CARD protocol.


2. Terminology

   Mobile Node (MN)

   A Mobile Node is an IP host capable of moving its point of
   attachment to the Internet.

   Access Point (AP)

   A radio transceiver by which a MN obtains Layer 2 connectivity with
   the wired network.

   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.





CARD Design Team       Expires û September 2003               [Page 3]


Internet-Draft     Candidate Access Router Discovery        March 2003

   Candidate AR (CAR)

   An AR to which a MN has a choice of performing IP-level handover.
   This implies that the MN has the right radio interface to connect to
   an AP that is served by this AR, as well as the coverage of this AR
   overlaps with that of the AR to which the MN is currently attached
   to.

   Capability of AR

   A characteristic of the service offered by an AR that may be of
   interest to a MN when the AR is being considered as a handover
   candidate.

   L2 ID

   Identifier of an AP, that uniquely identifies that AP. For example,
   in 802.11 PCF, this could be a MAC address of an AP.

   Target AR (TAR)

   An AR with which the procedures for the MN's IP-level handover are
   initiated. The TAR is selected after running a TAR Selection
   algorithm that takes into account the capabilities of CARs,
   preferences of the MN and any other local policies.


3. CARD Protocol Functions

   A CARD protocol accomplishes the following functions.


3.1 Reverse Address Translation

   This functionality refers to mapping the L2 ID of a new AP that the
   MN can hear, to the IP address of the CAR that connects to the new
   AP. In cases where the MN can acquire IP connectivity with CARs
   prior to making handover decisions, this functionality is trivially
   realized.

   However, if a MN can only listen to L2 IDs of new APs prior to
   making decision about IP-level handover to CARs, a special mechanism
   is needed for reverse address translation. This could be realized
   via cached information in the MN. Alternatively, the MN may seek the
   help of the current AR, wherein the MN sends L2 IDs of new APs to
   the current AR and expects it to resolve the L2 IDs to the IP
   address of CARs.





CARD Design Team       Expires û September 2003               [Page 4]


Internet-Draft     Candidate Access Router Discovery        March 2003


   Note: In some networks, such as cellular networks, link-layer
   technology may be capable of delivering the L2 ID of the new AP to
   the current AR. In this case the current AR can send CAR address
   information to a MN without receiving an explicit request for
   reverse address translation before.

   Finally, few comments are in order. First, note that the new AR can
   be in a different subnet than that of the current AR (even far away
   from the current AR in terms of IP hops). Second, when the MN
   delivers L2 IDs of APs to the reverse address translation module,
   implicit is the assumption that MN is satisfied with the signal
   strength of the new APs. Lower level criteria such as signal
   strength are out of scope of capabilities that we refer to in the
   CARD protocol. Finally, establishment of a L2 security association
   between a MN and individual AP(s) is assumed to be performed in
   accordance with the relevant L2 mechanism, and is outside the scope
   of the CARD protocol.


3.2 Discovery of CAR Capabilities

   Information about capabilities of CARs can assist the MN in making
   optimized handover decisions. This capability information serves as
   input to the TAR selection algorithm. Some of the capability
   parameters of CARs can be static, some others can change only on a
   long time scale, while the rest can be highly dynamic. Definition of
   capabilities is out of scope of the CARD protocol design. Encoding
   rules for capabilities and the format of a capability container for
   capability transport are specified in section 5.

   If the MN can establish robust IP connectivity with CARs before
   making handover decisions, the MN can directly ask for capability
   information from the CARs. Alternatively, certain capabilities may
   be periodically transmitted over downlink channels.

   On the other hand, if the MN cannot establish IP connectivity with
   CARs before making handover decisions, the current AR can assist the
   MN in retrieving capability information from the CAR.













CARD Design Team       Expires û September 2003               [Page 5]


Internet-Draft     Candidate Access Router Discovery        March 2003



4. CARD Protocol Operation

   There are two modes of CARD protocol operation, namely the MN-
   orchestrated CARD and the network-assisted CARD. These are described
   below.


4.1 MN-Orchestrated CARD

   In this mode, the MN performs CARD without any assistance from the
   current AR. For this, the MN needs to have a capability to establish
   IP connectivity with a CAR, while still being connected to its
   current AR at IP level. In this case, the MN by itself discovers
   capabilities of a CAR over the IP connectivity it establishes with
   the CAR. The MN then performs TAR selection.


   Figure 1 describes the timing diagram of MN-Orchestrated CARD. In
   this mode of operation while being connected with current AR, a MN
   establishes the IP layer connectivity with the serving AR of the
   newly discovered AP and then obtains the capabilities from it. The
   MN discovers the new access point ID during the periodic L2 scan of
   the non-IP-connected interfaces. Subsequently, the MN requests the
   capabilities of the newly discovered CAR by sending MN-AR CARD
   Request ICMP options. The CAR in turn returns the capabilities to
   the MN by sending AR-MN CARD Reply ICMP options. The capabilities
   are encoded as sub-options of the AR-MN CARD Reply ICMP option. The
   MN-AR CARD Request and the AR-MN CARD Reply ICMP options are either
   piggybacked upon ongoing Router Advertisement/Solicitation messages
   or sent as part of new ICMP messages. Section 5 describes the format
   of the ICMP options as well as the header of the new ICMP message
   required for delivering CARD options in stand-alone mode.


















CARD Design Team       Expires û September 2003               [Page 6]


Internet-Draft     Candidate Access Router Discovery        March 2003



   MN               current AR             CAR1                  CAR2
   |       Existing      |                   |                     |
   |    IP Connectivity  |                   |                     |
   |<------------------->|                   |                     |
   |                     |                   |                     |
   | <~ ~ ~ L2-SCAN (1)  |                   |                     |
   |                     |                   |                     |
   |         Establish IP connectivity  (2)  |                     |
   |<--------------------------------------->|                     |
   |                     |                   |                     |
   |                     |                   |                     |
   |                     |                   |                     |
   |                     |                   |                     |
   |    MN-AR CARD Request ICMP Option (3)   |                     |
   |---------------------------------------->|                     |
   |                     |                   |                     |
   |                     |                   |                     |
   |      AR-MN CARD Reply ICMP Option (4)   |                     |
   |<----------------------------------------|                     |
   |                     |                   |                     |
   |                     |                   |                     |
   |                     |                   |                     |
   |                 Establish IP Connectivity (2)                 |
   |<------------------------------------------------------------->|
   |                     |                   |                     |
   |                     |                   |                     |
   |                MN-AR CARD Request ICMP Option (3)             |
   |-------------------------------------------------------------->|
   |                     |                   |                     |
   |                     |                   |                     |
   |                AR-MN CARD|Reply ICMP Option   (4)             |
   |<------------------------------------------------------------- |
   |                     |                   |                     |
   |                     |                   |                     |

   Figure 1: MN Orchestrated CARD timing diagram


4.2 Network-Assisted CARD

   This mode caters to the case where the MN has IP layer connectivity
   with the current AR only. However, the MN is capable of listening to
   the L2 beacons from the neighboring AP(s) and thereby deducing their
   L2 ID(s). For example, 802.11 families of MN or cellular handsets
   with the mobile assisted handover capability are capable of
   performing the aforementioned functions.




CARD Design Team       Expires û September 2003               [Page 7]


Internet-Draft     Candidate Access Router Discovery        March 2003

   The MN discovers the L2 ID of an AP during L2 scan process. The MN
   passes on one or more L2 ID(s) to its current AR and the current AR
   resolves it to the IP address of the CAR. For this, the current AR
   first checks if the mapping is available locally in its cache. If
   not, the current AR queries a CARD server with the said L2 ID and
   the CARD server in turn returns the IP address of the CAR to the
   current AR. The current AR then directly contacts the CAR and
   performs capability discovery with it. The current AR then passes on
   the IP address of the CAR and its capabilities to the MN. When the
   handoff is imminent, the MN runs the TAR selection algorithm to
   choose one AR as a target for handover from the set of CARs and
   their capabilities it has learned through the CARD protocol. The
   network-assisted CARD protocol operation is illustrated in Figure 2
   below.



                                +----------+
                  +------------>|   CARD   |<-------------+
                  |+------------|  Server  |-------------+|
                  ||            +----------+             ||
                  ||                                     ||
                  ||             ~~~~~~~~~~~             ||
      (3)AR-Server||(4)AR-Server{           }            || (0) CARD
           CARD   ||    CARD   {             }           ||Registration
          Request ||   Reply  {    IP Cloud   }          ||Request/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 2: CARD Protocol Overview (Network Assisted Mode)








CARD Design Team       Expires û September 2003               [Page 8]


Internet-Draft     Candidate Access Router Discovery        March 2003



   Note on TAR selection at current AR: Throughout this draft, we have
   assumed that TAR selection is always performed on the MN. However,
   there was also interest in the working group to enable TAR selection
   on the current AR. In this case, there is a need to inform the
   current AR about its requirements, so that the current AR can make
   appropriate choice of a TAR from the set of CARs and their
   capabilities. TAR selection on the current AR has not been discussed
   in this draft as the working group consensus is pending on it.

   Note on capability pre-filtering:

   In case of implementing TAR selection in the MN, CAR capabilities
   are required to be conveyed to the MN as input to the TAR selection
   algorithm. The following approaches can be used for this purpose:


   (A) Providing full capability set for TAR selection

   The MN receives the full set of capability information from the
   sender of capabilities. In the MN orchestrated mode, this sender is
   the CAR, while in the network assisted mode it is the current AR.

   Since no MN preferences for capabilities are to be transmitted to
   the current AR, but the full set of capability information is to be
   conveyed to the MN, this approach is "uplink optimized".


   (B) Providing partial capability set for TAR selection

   The MN informs the sender about the capabilities of interest. In the
   MN orchestrated mode, this sender is the CAR, while in the network
   assisted mode it is the current AR. In response, the sender sends a
   subset of the CARs' capabilities to the MN to be used as input for
   the TAR selection function.

   Since this approach considers a reduced set of capabilities to be
   sent to the MN but assumes a set of preferences to be sent
   previously to the current AR, this approach is "downlink optimized".

   As an enhancement to approach (B), context transfer (CT) framework
   [4,5] can help to avoid sending the MN's preferences for pre-
   filtering the capability information to the current AR for each
   handover event. After the MN's preferences for pre-filtering have
   been provided to the current AR once, this information can be
   transferred to the selected TAR by means of CT mechanisms.





CARD Design Team       Expires û September 2003               [Page 9]


Internet-Draft     Candidate Access Router Discovery        March 2003




   Figure 3 describes the timing diagram of the Network Assisted CARD.
   It is to be noted that in Figure 3, the CAR registration process is
   not shown in critical path of the CARD discovery process. The CARs
   register with the CARD server when the CAR is initialized or when
   status of some of the L2 AP associated with the CAR or the
   capability associated with the CAR change. The CAR MAY also
   periodically register with the CARD server to update its capability
   as well as the list of the current AP(s) being supported by it.

   The CAR discovery process is initiated as soon as a mobile node
   discovers the link layer ID of nearby AP during periodic L2 scan
   process. The MN sends L2 ID of the AP to the connected AR in MN-AR
   CARD Request ICMP option to obtain the identity and the capabilities
   of the associated CAR. If not available in local cache, the current
   AR subsequently sends AR-Server CARD Request message to the CARD
   server to resolve the IP address of the serving AR of the newly
   discovered AP. The CARD server then resolves the link layer ID to
   the IP address of the CAR and returns the identity of the CAR as
   well as available static capabilities to the requesting AR in the
   Server-AR CARD Reply message. The capabilities are encoded according
   to the encoding rule described in section 5.1.4 and conveyed in a
   capability container attached to the Server-AR CARD Reply message.
   Upon receipt of the Server-AR CARD Reply message, the current AR
   extracts the IP address of the CAR and in turn requests remaining
   capabilities by sending AR-AR CARD Request message to the CAR. The
   CAR subsequently conveys its capabilities to the requesting AR in
   AR-AR CARD Reply message. Upon receipt of the AR-AR CARD Reply
   message, the current AR caches the capabilities as well as the L2-L3
   mapping information in local cache and encodes the capabilities as
   the sub-options of the AR-MN CARD Reply ICMP options. The AR-MN CARD
   reply ICMP options are conveyed to the Mobile Node either as
   piggybacked options of an outgoing FMIP Proxy Router Advertisement
   message or the options of the new AR-MN CARD ICMP message. The
   format of the new MN-AR ICMP message is described in section 5.1.















CARD Design Team       Expires û September 2003              [Page 10]


Internet-Draft     Candidate Access Router Discovery        March 2003





   MN                current AR         CARD Server               CAR
   |                     |                   |               (Candidate
   |                     |                   |                   Access
   |                     |                   |                  Router)
   |                     |                   |                     |
   |                     |                   |   Registration Req  |
   |                     |                   |<--------------------|
   |  <~ ~ ~ L2-SCAN (1) |                   |  Registration Reply |
   |                     |                   |-------------------->|
   |                     |                   |                     |
   |                     |                   |                     |
   |MN-AR CARD Req ICMP  |                   |                     |
   |     Option (2)      |                   |                     |
   |-------------------->|                   |                     |
   |                     |  AR-Server        |                     |
   |                     |  CARD Req (3)     |                     |
   |                     |------------------>|                     |
   |                     |    Server-AR      |                     |
   |                     |   CARD Reply (4)  |                     |
   |                     |<----------------- |                     |
   |                     |                   |                     |
   |                     |            AR-AR CARD Req (5)           |
   |                     |---------------------------------------->|
   |                     |                   |                     |
   |                     |            AR-AR CARD Reply (6)         |
   |                     |<----------------------------------------|
   |                     |                   |                     |
   | AR-MN CARD Reply    |                   |                     |
   | ICMP Options (7)    |                   |                     |
   |<--------------------|                   |                     |
   |                     |                   |                     |
   |                     |                   |                     |
   |                     |                   |                     |
   |                     |                   |                     |
   |                     |                   |                     |
   |                     |                   |                     |

   Figure 3: Network Assisted CARD timing diagram










CARD Design Team       Expires û September 2003              [Page 11]


Internet-Draft     Candidate Access Router Discovery        March 2003


5. Protocol Messages

5.1 CARD Messages for the interface MN - AR

5.1.1 CARD Main Header Format

   Hosts and Access Routers use the CARD ICMP-type main header when
   CARD protocol messages, to be exchanged between a MN and an AR,
   cannot be piggybacked by another outgoing ICMP-type message, as for
   example for Fast-MIPv6 purposes.

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |     Type      |     Code      |          Checksum             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                            Reserved                           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   Options ...
         +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

         Source Address:
                        An IP address assigned to the sending
                        interface.

         Destination Address:
                        An IP address assigned to the receiving
                        interface.

         Hop Limit:     255

         Authentication Header:
                        The sender SHOULD include the Authentication
                        Header, based on the previously established
                        Security Association between the sender and the
                        receiver.

      ICMP Fields:

         Type           T.B.A (To be assigned)

         Code           0

         Checksum       The ICMP checksum.

         Reserved       This field is unused. It MUST be initialized
                        with zero by the sender and MUST be ignored by


CARD Design Team       Expires û September 2003              [Page 12]


Internet-Draft     Candidate Access Router Discovery        March 2003

                        the receiver.

   Valid Options:

         CARD Request: The CARD Request allows entities to request CARD
                       specific information. To process the CARD
                       Request message on the receiver side, further
                       sub-option must be carried with the message,
                       serving as input for 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. Further sub-options
                       will be associated with the CARD Reply message.

   Valid Sub-Options:

         Layer-2 ID:
                        The Layer-2 ID carries information about the
                        type of 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.

         Preferences sub-option:
                        The Preferences sub-option carries information
                        about attributes of interest for the requesting
                        entity. Attributes are encoded according to the
                        AVP encoding rule as described in section
                        5.1.4. For settings of AVP Code and Data field,
                        please see section 5.1.3.2. This sub-option is
                        used only in case of performing capability pre-
                        filtering on ARs, which is referred to as
                        option to network assisted CARD and is
                        described in section 4.2.

         Requirements:
                        The Requirements sub-option carries information
                        about attribute-value pairs required for TAR
                        selection to the entity performing TAR
                        selection. Currently, only the MN performs TAR
                        selection, hence, this sub-option is not used
                        so far, as long as working group consensus on
                        this issue is pending (please refer to section
                        4.2). Attribute-value pairs are encoded
                        according to the AVP encoding rule as described
                        in section 5.1.4. For settings of AVP Code and
                        Data field, please see section 5.1.3.3.


CARD Design Team       Expires û September 2003              [Page 13]


Internet-Draft     Candidate Access Router Discovery        March 2003


         Capability container:
                        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:
                        The Address sub-option carries information on a
                        resolved AR's IP address. The associated AR is
                        indicated either as a CAR or as a selected TAR,
                        depending on the protocol operation.


5.1.2 CARD Options Format

   All options are of the 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     |              ...              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         ~                              ...                              ~
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Fields:

         Type:          8-bit identifier of the type of option. The
                        options defined in this document are:

             Option Name                             Type
          --------------------------------------------------
          MN-AR CARD Request                         T.B.A
          MN-AR CARD Reply                           T.B.A


         Length:        8-bit unsigned integer. The length of the
                        option including the type and length fields in
                        units of octets.  The value 0 is invalid.












CARD Design Team       Expires û September 2003              [Page 14]


Internet-Draft     Candidate Access Router Discovery        March 2003


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     |P|           Flags             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                        Sequence Number                        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |     Sub-Options
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -  -  -


   Fields:

      Type:    T.B.A

      Length:  The length of the option in units of octets, including
               the type and length fields as well as sub-options.

      Flags:   P-bit:   Indicates Piggybacking capability of the
                        sender.
               Remaining flags are reserved and MUST be initialized
               with 0.

      Sequence Number:
               Allows correlating requests with replies.


   Valid Sub-Options:

      - L2-ID sub-option
      - Preferences sub-option
      - Requirements sub-option


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     |P|           Flags             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                         Sequence Number                       |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |     Sub-Options
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -




CARD Design Team       Expires û September 2003              [Page 15]


Internet-Draft     Candidate Access Router Discovery        March 2003


   Fields:

      Type:    T.B.A

      Length:  The length of the option in units of octets, including
               the type and length fields as well as sub-options.

      Flags:   P-bit:   Indicates piggybacking capability of the
                        message sender.
               Remaining flags are reserved and MUST be initialized
               with 0.

      Sequence Number:
               Allows correlating requests with replies.


   Valid Sub-Options:

      - L2-ID sub-option
      - Capability Container sub-option
      - Address sub-option


5.1.3 Sub-Options Format

   All Sub-Options are of the 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 . . .
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Sub-Option Type:  8-bit identifier of the type of option. The
                     Sub-Options defined in this document are:


            Sub-Option Name                         Type
            --------------------------------------------
            L2-ID                                   T.B.A
            Preferences                             T.B.A
            Requirements                            T.B.A
            Capability Container                    T.B.A
            Address                                 T.B.A


   Option-Length: 8-bit unsigned integer. The length of the
                  option including the type and length fields in


CARD Design Team       Expires û September 2003              [Page 16]


Internet-Draft     Candidate Access Router Discovery        March 2003

                  units of octets. The value 0 is invalid.


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  |    L2-Type    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |      L2-ID . . .
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -


   Sub-Option Type:
                  T.B.A

   Sub-Option Length:
                  Length of the Sub-Option (including type and length
                  Fields as well as L2 type indicator) in units of 8
                  octets.

   Context-ID:    Identifies matching L2-ID, IP address and capability
                  information, when coming with separated sub-options.

   L2 type:       Indicates the interface type
                  (Ethernet, IEEE802.11b, ...).

   L2-ID:         The variable length layer-2 identifier of an
                  Individual CAR's Access Point. (bit and byte ordering
                  specifics?)


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

   Sub-Option Type:
                  T.B.A

   Sub-Option Length:
                  Length of the Sub-Option (including type and length
                  fields) in units of 8 octets.

   Preferences:   AVP encoded preferences (see section 5.1.4).



CARD Design Team       Expires û September 2003              [Page 17]


Internet-Draft     Candidate Access Router Discovery        March 2003

   AVPs MUST be encoded according to the rule described in section
   5.1.4. Only ATTRIBUTES (AVP Code) need to be set. VALUE indicator
   (Data) will not be processed and can be omitted. 'AVP Length' field
   is to be set appropriately.


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:
                  T.B.A

   Sub-Option Length:
                  Length of the Sub-Option (including type and length
                  fields) in units of octets.

   Requirements:  AVP encoded requirements (see section 5.1.4)

   AVPs MUST be encoded according to the rule described in section
   5.1.4. Both, ATTRIBUTES (AVP Code) and VALUES (Data) MUST be set.


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 |P|           Flags             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  Context-ID   |                   Reserved                    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |             AVPs
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -


   Sub-Option Type:
                  T.B.A

   Sub-Option Length:
                  Length of the Sub-Option (including type and length
                  fields as well as AVPs) in units of 8 octets.




CARD Design Team       Expires û September 2003              [Page 18]


Internet-Draft     Candidate Access Router Discovery        March 2003

   Flags:         P-flag:  Indicates piggybacking capability of a CAR.
                  This flag allows a MN already after CARD process to
                  know about a selected new AR's piggybacking
                  capability.

                  Remaining flags are reserved and MUST be initialized
                  with 0.

   Context-ID:    Identifies L2-ID, IP address and capability triples,
                  coming with separated sub-options.

   Reserved:      This field MUST be initialized with 0.

   AVPs:          AVPs are a method of encapsulating capability
                  information relevant for the CARD protocol. See
                  section 5.1.4 for AVP encoding rule.


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 | Address Type  |   Node Type   |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   Context-ID  |                  Reserved                     |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           Address . . .
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -

   Sub-Option Type:
                  T.B.A

   Sub-Option Length:
                  Length of the Sub-Option (including type and length
                  fields) in units of octets.

   Address Type:  Indicates the type of the address.

                              0x01  IPv4
                              0x02  IPv6

   Node Type:     Indicates the node type the subsequent address is
                  associated to.







CARD Design Team       Expires û September 2003              [Page 19]


Internet-Draft     Candidate Access Router Discovery        March 2003

   Currently, the following node types are specified:

                              0x01  CAR Address
                              0x02  TAR Address

   Context-ID:    Identifies L2-ID, IP address and capability triples,
                  coming with separated sub-options.

   Address:       The Target Access Router's IP address.


5.1.4 CARD AVP encoding

          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                    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |S|  Reserved   |             Attribute Lifetime                |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |             Data . . .
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -

   AVP Code:      Identifies the attribute uniquely.

   Flags:         S:       Static   1: static attribute, lifetime field
                                       is ignored

                                    0: lifetime field indicates the
                                       attribute's lifetime. If
                                       lifetime is set to 0, the
                                       attribute value is valid only
                                       for this single request!

                  Remaining flags are reserved and MUST be set to 0.

   AVP Length:    The three octet AVP length field indicates the
                  number of octets in this AVP, including the AVP Code,
                  AVP Flags, AVP Length, Lifetime and Data.













CARD Design Team       Expires û September 2003              [Page 20]


Internet-Draft     Candidate Access Router Discovery        March 2003


5.2 CARD Messages for the interface between ARs (AR - AR)

5.2.1 Protocol transport (AR-AR)

   For the CARD protocol operation between a MN's current AR and CARs
   on the network side, UDP is used as transport for CARD protocol
   messages. A UDP port for CARD is to be assigned.

   To authenticate protocol messages between ARs, the IPSec
   Authentication header is to be used.


5.2.2 Protocol main header

   Protocol main header comprises the first 8 octets:
          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |Version| Flags |     Type      |            Length             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                        Sequence Number                        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |            Payload ...
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -


   Version:       Indicates the version of the protocol.

   Flags:         All flags are reserved and MUST be set to 0.

   Type:          Message type.


         Message types specified for this interface:

              Message                     Type
          --------------------------------------
          AR-AR CARD Request              0x01
          AR-AR CARD Reply                0x02


   Length:        Length of the subsequent payload in octets.

   Sequence number:
                  Allows correlating requests with responses.






CARD Design Team       Expires û September 2003              [Page 21]


Internet-Draft     Candidate Access Router Discovery        March 2003


5.2.3 Protocol payload types

   Payload types and encoding rules are the same as described for the
   various sub-option types in section 5.1 for the Interface MN-AR.
   Same TLV-encoded format is used to attach the options to the
   protocol main header.


5.3 CARD Messages for the interface between an AR and the CARD server

5.3.1 Protocol transport (AR-Server function)

   For the CARD protocol operation between an AR and the CARD server
   function on the network side, UDP is used as transport for CARD
   protocol messages. A UDP port for CARD is to be assigned.

   Note:
   However, if for security and reliability reasons use of, for
   example, RADIUS or DIAMETER is preferable (assuming the CARD server
   function to be integrated with a RADIUS/AAA server), CARD protocol
   messages and payload is to be encoded appropriately.
   This needs to be discussed.

   To authenticate protocol messages between ARs, the IPSec
   Authentication header is to be used.

5.3.2 Protocol main header

   The protocol main header for this interface is the same as used for
   the interface between ARs on network side, and is described in
   section 5.2.2.

   Since ARs need to register with the CARD server function, two
   additional message types have been specified, which is a CARD
   REGISTRATION REQUEST and a CARD REGISTRATION REPLY message.

   The following table lists message types specified for CARD between
   an AR and the CARD server function:

         Message types specified for this interface:

              Message                     Type
            ------------------------------------
            AR-Server CARD Request        0x03
            AR-Server CARD Reply          0x04
            CARD Registration Request     0x05
            CARD Registration Reply       0x06




CARD Design Team       Expires û September 2003              [Page 22]


Internet-Draft     Candidate Access Router Discovery        March 2003



   For the registration related message types, an additional payload
   type is required and described in section 5.3.3.


5.3.3 Protocol payload types

   Payload types and encoding rules are the same as described for the
   various sub-option types in section 5.1 for the Interface MN-AR.
   Same TLV-encoded format is used to attach the options to the
   protocol main header.

   For the registration of an AR with a CARD server function, an
   additional payload type is required to indicate the lifetime of the
   AR's registration. The lifetime option is encoded as follows


          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     |           Reserved            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                           Lifetime                            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type:    T.B.A

   Length: 0x08  -  Length of the lifetime payload option in octets
                     (including type and length fields).

   Reserved:
            To be initialized with 0.

   Lifetime:
            Indicates the lifetime of a registration in seconds. If the
            lifetime is set to '0', this indicates a de-registration
            with a CARD server function.













CARD Design Team       Expires û September 2003              [Page 23]


Internet-Draft     Candidate Access Router Discovery        March 2003


5.4 Overview on sub-options'/payload types' usage

   The following table indicates which sub-options or payload types are
   relevant for the various interfaces in CARD protocol functions.


         Description                Type             Interface
                                             MN-AR   AR-Server   AR-AR
       ---------------------------------------------------------------
         L2-ID                      T.B.A      x         x
         Preferences                T.B.A      x                  x
         Requirements               T.B.A      x
         Capability Container       T.B.A      x         x        x
         Address                    T.B.A      x         x
         Lifetime                   T.B.A                x


6. Security Considerations

6.1 Security Associations

   The AR-CARD Server communication and AR-AR communication need to be
   protected using security associations between them. These security
   associations can be established using current best practices. For
   example, statically programmed passwords or certificates (note that
   ARs and CARD server are in the same administrative domain) can be
   used to create session keys for message protection using IPSec.
   Alternatively, IPSec policy framework may be used to push
   credentials on these network entities from the policy server, which
   in turn can be used to create session keys for message protection
   using IPSec. It is not the intent of the CARD protocol to define a
   mechanism to create AR-CARD server and AR-AR security associations.
   It is implicit that the MN will have a security association with the
   current AR.

   Note: For AR-AR messaging, the CARD protocol shares security
   requirements with FMIPv6 and CT. Thus a common solution to establish
   security association between ARs can be used for FMIPv6, CT and CARD
   protocol.


6.2 DoS Attack

   The MN-AR communication presents chances to an attacker. A rogue MN
   can use CARD as a Denial-of-Service (DoS) attack against an AR. It
   may also flood the backend AR-Server and AR-AR communications. If
   the MN undertakes a DoS attack by flooding the AR with real or bogus
   layer 2 addresses, the CARD should prevent it. Since the requests
   from a MN come from within its subnet, the AR may know who is


CARD Design Team       Expires û September 2003              [Page 24]


Internet-Draft     Candidate Access Router Discovery        March 2003

   sending the requests. One possible solution is to limit the number
   of requests from a MN within a unit of time. But still, the rogue MN
   may change its identity so that the AR cannot detect. Another
   solution may be to define a kind of 'scope ID'. This is something to
   be configured administratively, but would make detection of ARs,
   which are not CARs easier and avoids cache overflow. For example,
   operators may set their ARs' scope-IDs based on the rough location
   and ARs register their scope-IDs to a server. When a current AR
   requests the L2-L3 mapping from the server, the server returns the
   mapping with its scope-ID. The current AR detects that this AR is
   potentially no CAR. Then, it can avoid further attempts to perform
   reverse address translation and capability discovery for this AR.


6.3 CAR Cache Contamination

   When caching is allowed at AR, the issue of preventing cache
   contamination needs to be addressed. A MN provides the current AR
   with unauthenticated observations of AP identifiers that it can
   hear. Then the AR asks for the authenticated AR information via the
   CARD server. The CARD server can tell only that there is a
   registered AR with the given L2 address but it cannot tell whether
   the AR is a CAR of the current AR (Note that CAR needs to have an
   access point geographically adjacent to current AR). Now the current
   AR relies on the fact that a MN provided the L2 address matching to
   a registered AR. A malicious MN may provide a L2 address, which is
   the L2 address of a registered AR but not a CAR of the current AR,
   that is, no overlapping coverage with the current AR. Then the
   current AR will build a CAR cache table with IP addresses of ARs
   that are not CARs. This has implications on size of cache that can
   be allowed on ARs. A more serious implication is that if large
   number of non-CAR entries appear in AR cache, AR spends processing
   power in performing capability exchange procedures with them.

   However, this issue may not be a problem in actual handover cases.
   At the time of handover, the MN or AR will receive the layer 2
   address of the AP to which the MN is moving. Or the MN will match
   the AP layer 2 addresses in the CAR table with the address of the
   Aps it can hear. Thus, an AP address that is provided by a malicious
   MN but has no wireless connectivity to the CAR will get filtered out
   when the MN or AR uses the information for handover, so this issue
   can do no harm when the time of handover.

   Note: If cache contains bogus entries, hit ratio will go down. So,
   L2-IP mapping needs to be done from the CARD server. There is no
   guarantee, that answer from the CARD server will come in time for
   handover.





CARD Design Team       Expires û September 2003              [Page 25]


Internet-Draft     Candidate Access Router Discovery        March 2003


   This contaminated cache issue can be considered as a failure of the
   CAR cache table optimization. In addition to the æscope IDÆ solution
   described above, there is another possible solution for this
   optimization. The ARs can handle this by making the CARD information
   soft state, so that it times out the AP addresses if it doesnÆt
   receive a confirmation from another MN within a certain period of
   time. Thus, any bogus information has only limited lifetime, and
   even within that lifetime, it cannot do more than to occupy a table
   slot in the ARÆs memory. In fact, the AR can use the number of MNs
   reporting a particular address to weight the relevance of a reported
   AP. So, if 20 MNs report it, the AP address is more likely to stick
   around than if only 1 reports it. Note that this is not a protocol
   issue but an optimization issue for implementation.

   For additional security concerns, the reader is referred to [3].


7. IANA considerations

   This will be done later when the protocol proposal has been
   finalized.


8. References

   [1]Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

   [2]Trossen, D., Krishanmurthi, G. Chaskar, H., Kempf, J. ôIssues in
      candidate access router discovery for seamless IP-level
      handoffs", draft-ietf-seamoby-cardiscovery-issues-04.txt, work in
      progress, October 2002.

   [3]Krishanmurti, G., ôRequirements for CAR Discovery Protocolsö,
      draft-ietf-seamoby-card-requirements-02.txt, a work in progress,
      October 2002.

   [4]Kempf, J.,"Problem Description: Reasons For Performing Context
      Transfers Between Nodes in an IP Access Network", RFC 3374,
      September 2002.

   [5]Kenward, B.,"General Requirements for Context Transfer", draft-
      ietf-seamoby-ct-reqs-05.txt, a work in progress, October 2002.








CARD Design Team       Expires û September 2003              [Page 26]


Internet-Draft     Candidate Access Router Discovery        March 2003





9. Authors' Addresses

   Hemant Chaskar
   Nokia Research Center
   5 Wayside Road
   Burlington, MA 01803, USA
   Phone: 781 993 3785
   Email: Hemant.Chaskar@nokia.com

   Daichi Funato
   NTT DoCoMo USA Labs
   181 Metro Drive, Suite 300
   San Jose, CA 95110, USA
   Phone: +1 408-451-4736
   EMail: funato@docomolabs-usa.com

   Marco Liebsch
   NEC Network Laboratories
   Kurfuersten-Anlage 36 , 69115 Heidelberg
   Germany
   Phone: +49/(0)6221 90511 46
   Email: marco.liebsch@ccrle.nec.de

   Ajoy Singh
   Motorola Inc
   1501 West Shure Dr
   Phone: 847 632 6941
   Email: asingh1@email.mot.com



10. IPR Statements

   The IETF has been notified of intellectual property rights claimed
   in regard to some or all of the specification contained in this
   document. For more information consult the online list of claimed
   rights.

   Please refer to http://www.ietf.org/ietf/IPR for more information.









CARD Design Team       Expires û September 2003              [Page 27]


Internet-Draft     Candidate Access Router Discovery        March 2003





11. Copyright Notice

   "Copyright (C) The Internet Society (date). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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."


12. Acknowledgements

   The CARD design team would like to thank Erik Nordmark for providing
   valuable insight about the piggybacking of CARD options upon FMIPv6
   messages. In addition, the design team would like to thank (in
   alphabetical order) Eunsoo Shim, Govind Krishnamurthi, James Kempf,
   Madjid Nakhjiri, Pete McCann, Rajeev Koodli, and other members of
   the Seamoby WG for their valuable comments on the previous version
   of the draft as well as the general CARD related discussion and
   feedback on the WG mailing list.









CARD Design Team       Expires û September 2003              [Page 28]