Internet DRAFT - draft-han-mipshop-ncoaconf-fmipv6


IETF MIPSHOP Working Group                                        Y. Han
Internet-Draft                                               SAMSUNG AIT
Expires: July 15, 2004                                  January 15, 2004

    A Supplementary Scheme for New Care-of Address Configuration and
                         Confirmation in FMIPv6

Status of this Memo

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

   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://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on July 15, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.


   This document proposes a new care-of address (NCoA) configuration and
   confirmation scheme for the Mobile IPv6 fast handover protocol
   (FMIPv6). The goal of this proposal makes FMIPv6 address
   configuration and confirmation 'very fast' and its confirmation
   result 'always successful'. The proposed scheme can become a
   supplementary function implemented in only nodes which play a role of
   new access router in FMIPv6.

Han                      Expires July 15, 2004                  [Page 1]
Internet-Draft     A Supplementary Scheme for FMIPv6        January 2004

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  5
   2.1 Duplication-free Address Generation  . . . . . . . . . . . . .  5
   2.2 Passive-Proxy for Duplication-free Addresses . . . . . . . . .  5
   2.3 NAR operation  . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
       Normative References . . . . . . . . . . . . . . . . . . . . .  8
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  8
       Intellectual Property and Copyright Statements . . . . . . . .  9

Han                      Expires July 15, 2004                  [Page 2]
Internet-Draft     A Supplementary Scheme for FMIPv6        January 2004

1. Introduction

   FMIPv6 (Fast Handover for Mobile IPv6) [1] describes a protocol to
   replace MIPv6 (Mobile IPv6) [2] movement detection algorithm and NCoA
   (New Care-of Address) configuration procedure. Conceptually, the
   protocol consists of three phases:

   -  FMIPv6 enables an MN (Mobile Node) to detect that it is now moving
      to a new subnet by providing the new access point identifier and
      receiving the associated subnet prefix information, if at all
      possible, when the MN is still connected to its current subnet.
      The MN may do this after establishing connectivity with PAR, and
      also do this at any time during its sojourn on its current point
      of attachment.

   -  The MN also formulates a prospective NCoA, again if at all
      possible, when still present on current subnet. Furthermore, in
      order to make the MN allocate the NCoA to its interface
      immediately after attaching to new subnet, FMIPv6 provides the
      NCoA confirmation procedure, which is executed before or during MN
      switches its subnet.

   -  FMIPv6 specifies a tunnel establishment typically between PCoA
      (Previous CoA) and NCoA so that the MN can continue to receive or
      send packets while it completes the binding update to HA and CNs
      on the new subnet. When feasible, this tunnel establishment is
      done before MN attaches to new subnet. Otherwise, it should be
      established immediately after MN attaches to new subnet.

   The scenario in which an MN receives the positive result about the
   confirmation of its prospective NCoA on the current subnet is called
   'predictive' mode of operation. The scenario in which an MN checks
   the uniqueness of NCoA after MN attaches to new subnet is called
   'reactive' mode of operation.

   Although MN initiates the NCoA confirmation and tunnel establishment
   at early time on the current subnet, FMIPv6 would fall into the
   reactive mode if MN could not receive the confirmation result on the
   current subnet. At this case, MN should (re)send FBU, which is
   encapsulated in FNA, as soon as it attaches to NAR. This procedure
   will cause wireless resources to be more used and an additional
   processing at NAR is required to check whether or not the NCoA is
   already confirmed (or whether or not the NCoA is already used by
   other node).

   In addition to that, if the proposed NCoA is rejected during the NCoA
   confirmation procedure, MN may configure NCoA by itself (using RFC
   2462 DAD algorithm [3]) so that handover latency becomes long. In

Han                      Expires July 15, 2004                  [Page 3]
Internet-Draft     A Supplementary Scheme for FMIPv6        January 2004

   order to achieve more reduction of handover latency, it is required
   that 'predictive' mode occurs more frequently than 'reactive' mode.
   So, it is so demanded that the NCoA confirmation should be done
   'promptly' and its result should be always 'positive'.

   In this draft, we propose an NCoA configuration and confirmation
   scheme for FMIPv6. This scheme is an 'add-on' function implemented in
   NAR (New Access Router). It is not a new IPv6 address configuration
   scheme, but a supplementary one incorporated with the existing
   stateless and stateful address configurations.

Han                      Expires July 15, 2004                  [Page 4]
Internet-Draft     A Supplementary Scheme for FMIPv6        January 2004

2. Protocol Description

   The goal of this proposal makes FMIPv6 address configuration and
   confirmation 'very fast' and its confirmation result 'always
   successful'. In this section, we will describe this proposal in
   detail. The proposal consists of the following three steps:

2.1 Duplication-free Address Generation

   If AR (Access Router) has an interface connected to a subnet where an
   MN can move, it must create and manage a 'Duplication-free Address
   Pool' associated with the interface. AR can randomly generate
   globally routable addresses as background process. The default random
   address generation procedure is similar with one described in RFC
   3041 [5]. However, a procedure, if any, can be used for the address
   generation. If stateful address configuration is available in the
   network, AR can request an address from DHCPv6 server.

   On generating or obtaining an address, AR must perform RFC 2462 DAD
   on the address. Only after successful DAD, AR reserves the address
   into its 'Duplication-free Address Pool'.

   The number of address generated or obtained initially is at least
   'CAPACITY_OF_POOL'. By default, 'CAPACITY_OF_POOL' is 10, but it
   should be able to be configured.

2.2 Passive-Proxy for Duplication-free Addresses

   As soon as an address is stored in the pool, AR MUST begin to act as
   a proxy for the address 'passively'. While AR is serving as
   Passive-Proxy for an address, it MUST NOT use Proxy Neighbor
   Discovery (Section 7.2.8 in [4]). So, AR MUST NOT multicast onto its
   link an unsolicited NA (Neighbor Advertisement) message, to advertise
   the AR's own link-layer address for the address. This behavior's
   reason is because AR does not have to intercept packets delivered to
   the address. Moreover, such packets may not be created or delivered
   from any node until an MN gets and uses it as its NCoA.

   Also, it MUST NOT reply to an NS (Neighbor Solicitation) message with
   the Target Address field set to one of addresses stored at the pool.
   Particularly when AR receives such an NS with the purpose of DAD
   executed from any other node (in this case, the Source Address field
   in the NS message is set to the unspecified address), it MUST
   silently delete (thereby, relinquish) the address specified in the
   Target Address field from its 'Duplication-free Address Pool'. At any
   time of such deletion, AR SHOULD generate a new address (or obtaining
   it from DHCPv6 Server) and keep the total number of addresses in the
   pool being 'CAPACITY_OF_POOL'. By obeying these rules, AR can keep

Han                      Expires July 15, 2004                  [Page 5]
Internet-Draft     A Supplementary Scheme for FMIPv6        January 2004

   the reserved addresses unique lastingly until they are allocated into
   an MN.

2.3 NAR operation

   Sometime after exchanging RtSolPr (Router Solicitation for Proxy) and
   PrRtAdv (Proxy Router Advertisement), MN sends FBU (Fast Binding
   Update) from PAR (Previous Acess Router)'s link. On receiving FBU,
   PAR sends HI (Handover Initiation) to NAR. PAR may set 'S' bit in HI
   and thereby request NCoA. Whether or not PAR sets 'S' bit in HI, NAR
   will assign a duplication-free address. In response to processing the
   HI message, the NAR

   1) select a duplication-free address from its pool and delete it from
      the pool.

   2) create HAck (Handover Acknowledgement) sent to PAR as a reply to
      HI. At this time, 'Code' field in HAck is set as follows: If 'S'
      bit in the received HI is unset, 'Code' field is set to '2', which
      indicates 'Handover Accepted, NCoA in use'. If 'S' bit in the
      received HI is set, 'Code' field is set to '3', which indicates
      'Handover Accepted and NCoA is assigned'. Also, HAck always
      contains 'New Care-of Address' Option carrying the selected
      duplication-free address.

   3) start 'normal' proxying the address and create a proxy neighbor
      cache entry defending the address.

   After completely performing the above procedure, NAR checks if there
   are other jobs. If such jobs do not remain any more, NAR SHOULD try
   to generate a new address (or obtain it from DHCPv6 server), run DAD
   on the address, and reserve it into its pool so that NAR keeps the
   total number of duplication-free addresses being CAPACITY_OF_POOL.

   By setting '2' or '3' in the 'Code' field and including a
   duplication-free address in HAck, this add-on scheme forces MN to
   always use the address assigned from NAR's 'Duplication-free Address

Han                      Expires July 15, 2004                  [Page 6]
Internet-Draft     A Supplementary Scheme for FMIPv6        January 2004

3. Security Considerations

   The delivery of a duplication-free address are achieved with the
   exchange of pre-defined handover-related messages of FMIPv6. So,
   FMIPv6 itself will correctly authenticate the delivery of the


   [1]  Koodli, R., "Fast Handovers for Mobile IPv6",
        draft-ietf-mipshop-fast-mipv6-00 (work in progress), October

   [2]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
        IPv6", draft-ietf-mobileip-ipv6-18 (work in progress), July

   [3]  Thomson, S. and T. Narten, "IPv6 Stateless Address
        Autoconfiguration", RFC 2462, December 1998.

   [4]  Narten, T. and R. Draves, "Privacy Extensions for Stateless
        Address Autoconfiguration in IPv6", RFC 3041, January 2001.

   [5]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
        IP Version 6 (IPv6)", RFC 2461, December 1998.

Author's Address

   Youn-Hee Han
   SAMSUNG Advanced Institute of Technology
   i-Networking Laboratory
   San 14-1, Nongseo-ri, Giheung-eup
   Yongin-si, Gyeonggi-do  449-712

   Phone: +82 31 280 9585

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it


Han                      Expires July 15, 2004                  [Page 7]
Internet-Draft     A Supplementary Scheme for FMIPv6        January 2004

   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive

Full Copyright Statement

   Copyright (C) The Internet Society (2004). 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

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

   This document and the information contained herein is provided on an

Han                      Expires July 15, 2004                  [Page 8]