[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                       C. Vogt, Ed.
Internet-Draft                                                  R. Bless
Expires: August 4, 2004                                          M. Doll
                                                               T. K’fner
                                             Univ. of Karlsruhe, Germany
                                                        February 4, 2004


                 Early Binding Updates for Mobile IPv6
                draft-vogt-mip6-early-binding-updates-00

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://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 4, 2004.

Copyright Notice

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

Abstract

   The long latency associated with Mobile IPv6's home-address and
   care-of-address tests can significantly impact delay-sensitive
   applications. We propose a modified binding-update procedure that
   evades the latency of both address tests. The modified binding update
   runs in half, or less, of the time that a standard binding update
   takes. Moreover, the modified binding update is nearly equivalent to
   the standard procedure with respect to security, and it increases the
   resources required at the correspondent node only marginally. The
   modification is realized as an optional, and fully
   backward-compatible, extension to Mobile IPv6.



Vogt, Ed., et al.        Expires August 4, 2004                 [Page 1]

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4

   3.  Standard Binding Updates . . . . . . . . . . . . . . . . . . .  6

   4.  Early Binding Updates  . . . . . . . . . . . . . . . . . . . .  9
   4.1 Protocol Specification . . . . . . . . . . . . . . . . . . . . 10
   4.2 Concurrent Care-of Address Tests . . . . . . . . . . . . . . . 14
   4.3 Initial Care-of Address Registration . . . . . . . . . . . . . 15

   5.  Efficiency Considerations  . . . . . . . . . . . . . . . . . . 16
   5.1 Standard Binding Updates . . . . . . . . . . . . . . . . . . . 16
   5.2 Early Binding Updates  . . . . . . . . . . . . . . . . . . . . 18

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   6.1 Decoupled Address Tests  . . . . . . . . . . . . . . . . . . . 21
   6.2 Concurrent Care-of Address Tests . . . . . . . . . . . . . . . 23

   7.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24

   8.  Protocol Configuration Variables . . . . . . . . . . . . . . . 24

       References . . . . . . . . . . . . . . . . . . . . . . . . . . 24

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25

       Intellectual Property and Copyright Statements . . . . . . . . 27





















Vogt, Ed., et al.        Expires August 4, 2004                 [Page 2]

Internet-Draft           Early Binding Updates             February 2004


1. Introduction

   Mobility Support for IPv6 [1], or Mobile IPv6, allows a mobile node
   to change its point of network attachment without loosing
   higher-level communications connections. A mobile node has a
   preferably permanent "home address", by means of which the mobile
   node can be identified. In addition, the mobile node has a "care-of
   address", which is a topologically correct IP address at the mobile
   node's current location. The care-of address changes whenever the
   mobile node moves to a different location. If a mobile node and a
   correspondent node use route optimization, the correspondent node
   maintains a "binding" between the mobile node's home address and
   current care-of address. When the mobile node attaches to a different
   network, it initiates a "binding update", i.e., it signals to the
   correspondent node its new care-of address. We assume the application
   of route optimization in this document.

   Mobile IPv6 uses a "return routability" procedure to verify a binding
   update with respect to authenticity and validity. The return
   routability encompasses two tests: A home-address test authenticates
   the mobile node. It provides reasonable assurance to the
   correspondent node that the mobile node is the legitimate owner of
   the IP address which the mobile node claims to own as its home
   address. A care-of-address test checks the validity of the new
   care-of address. It provides reasonable assurance to the
   correspondent node that the mobile node is reachable through the IP
   address which the mobile node wishes to register as its care-of
   address.

   The return routability requires a minimum of processing resources and
   state at both the mobile node and the correspondent node.
   Furthermore, it does not depend on a trusted infrastructure, which
   would be expensive to build and maintain. A shortfall, however, is
   that the two address tests, though typically performed in parallel,
   constitute a considerable fraction of the binding-update latency.
   Both tests are potentially run over very long distances. This makes
   it difficult for delay-sensitive applications to hold up service
   quality when the mobile node changes its point of network attachment.

   In this document, we propose a strategy, Early Binding Updates, to
   move both address tests out of the critical period during which a new
   care-of address cannot yet be used. We find that an Early Binding
   Update runs in half, or less, of the time that a binding update
   defined in [1] takes. Moreover, we show that an Early Binding Update
   is nearly equivalent to the standard procedure with respect to
   security, and that it increases the resources required at the
   correspondent node only marginally. To facilitate differentiation, we
   will henceforth call the binding update defined in [1] a "standard



Vogt, Ed., et al.        Expires August 4, 2004                 [Page 3]

Internet-Draft           Early Binding Updates             February 2004


   binding update".

   Early Binding Updates are a minor extension to standard binding
   updates. They are fully compatible to the binding-update procedure
   defined in [1], in particular with the return routability. Early
   Binding Updates use two new messages, both of which have no effect if
   either communication end-point does not support them. All messages
   related to standard binding updates remain unchanged and retain their
   original meaning. We are currently working on a more detailed
   specification of Early Binding Updates including message formats and
   additions to [1]. The specification will be published in a future
   version of this Internet Draft.

   Section 2 provides a brief overview on Early Binding Updates. The
   overview is assumed to be sufficient for a hurried reader who does
   not want to read the in-depth discussion of the subsequent sections.
   Section 3 is a recap on the standard binding-update procedure defined
   in [1]. Section 4 provides the details of Early Binding Updates. We
   analyze the efficiency of Early Binding Updates in Section 5.
   Implications on security are examined in Section 6. We conclude in
   Section 7.



2. Overview

   In this section, we briefly describe Early Binding Updates. This
   section is assumed to be a sufficient survey for a hurried reader. We
   refer to Section 4 for more details on Early Binding Updates. Section
   3 provides a recap on standard binding updates.

   Early Binding Updates are a strategy to move both address test out of
   the critical period during which a new care-of address cannot yet be
   used. With Early Binding Updates, a mobile node executes a
   home-address test whenever a handover is imminent. If handovers
   cannot be anticipated, the mobile node may periodically repeat the
   home-address test. Either way, the mobile node has at hand a fresh
   Home Keygen Token when it changes its point of network attachment,
   and it does not need to wait for a lengthy home-address test during
   the binding update. Furthermore, the care-of-address test is executed
   in parallel with sending data to and from the new care-of address.
   This way, the mobile node does not need to wait for a lengthy
   care-of-address test during the binding update either. Note that [1]
   suggests running both address tests after a handover. However, the
   mobile node may trigger a home-address test before it moves without
   violating the protocol procedure.

   We introduce two new messages: an Early Binding Update message and an



Vogt, Ed., et al.        Expires August 4, 2004                 [Page 4]

Internet-Draft           Early Binding Updates             February 2004


   Early Binding Acknowledgement message. When the mobile node detects
   that it has moved to a different network, it configures a new care-of
   address. The mobile node then sends to the correspondent node an
   Early Binding Update message in order to tentatively register the new
   care-of address with the correspondent node. The mobile node just
   needs a Home Keygen Token to authenticate the Early Binding Update
   message. The mobile node may request the correspondent node to return
   an Early Binding Acknowledgement message by raising a flag in the
   Early Binding Update message. A conservative mobile node would wait
   for the Early Binding Acknowledgement message before using its new
   care-of address. An optimistic mobile node would start using its new
   care-of address as soon as having dispatched the Early Binding Update
   message. Whether conservative or optimistic, with Early Binding
   Updates, the mobile node can use its new care-of address about one
   round-trip time sooner than with standard binding updates.

   Having sent the Early Binding Update message, the mobile node
   initiates a care-of-address test as defined in [1]. When the
   care-of-address test completes, the mobile node sends to the
   correspondent node a standard Binding Update message as defined in
   [1]. The Binding Update message is to have the correspondent node
   change the status of the care-of-address registration from tentative
   to regular.

   When the correspondent node receives the Early Binding Update message
   from the mobile node, it creates a tentative binding-cache entry with
   the mobile node's new care-of address. The correspondent node uses
   the mobile node's new care-of address as soon as the binding-cache
   entry is in place. Thus, with Early Binding Updates, the
   correspondent node can use the mobile node's new care-of address
   about one round-trip time sooner than with standard binding updates.
   A tentative binding-cache entry's lifetime is limited to a few
   seconds, within which the correspondent node expects the mobile node
   to run a successful care-of-address test. When the correspondent node
   receives the Binding Update message, it extends the lifetime of the
   mobile node's tentative binding-cache entry to the regular lifetime
   proposed in [1]. The tentative binding-cache entry will be deleted,
   if the Binding Update message fails to be delivered to the
   correspondent node during the binding-cache entry's lifetime - which
   clearly is the case if the mobile node fails to run a successful
   care-of-address test. Further data packets will then be sent via the
   mobile node's home agent.

   Early Binding Updates are a fully backward-compatible extension to
   the binding-update procedure defined in [1]. All messages related to
   standard binding updates remain unchanged and retain their original
   meaning. Moreover, a mobile node may initiate an Early Binding Update
   without knowing whether or not this optimization is supported by the



Vogt, Ed., et al.        Expires August 4, 2004                 [Page 5]

Internet-Draft           Early Binding Updates             February 2004


   correspondent node. If the correspondent node does not support Early
   Binding Updates, the mobile node's Early Binding Update message has
   no effect, and the binding-update procedure is automatically reduced
   to the standard procedure.



3. Standard Binding Updates

   This section is a recap on the standard binding-update procedure,
   which allows a mobile node to register its care-of address with a
   correspondent node. The procedure is depicted in Figure 1. The
   complete definition can be found in [1].


        Mobile Node            Home Agent        Correspondent Node

           ~~~~~ [Handover]

              Binding Update (1)
             |-------------------->|

              Home Test Init (2)
             |-------------------->|-------------------->|

              Care-of Test Init (3)
             |------------------------------------------>|

              Binding Acknowledgement (4)
             |<--------------------|

              Home Test (5)
             |<--------------------|<--------------------|

              Care-of Test (6)
             |<------------------------------------------|

              Binding Update (7)
             |------------------------------------------>|

              Binding Acknowledgement (8)
             |<------------------------------------------|

                   Figure 1: Standard Binding Update


   When the mobile node detects that it has moved to a different
   network, it configures a new care-of address. The mobile node then



Vogt, Ed., et al.        Expires August 4, 2004                 [Page 6]

Internet-Draft           Early Binding Updates             February 2004


   sends to its home agent a Binding Update message (1). The Binding
   Update message informs the home agent about the mobile node's new
   care-of address. It is authenticated by means of an IPsec security
   association between the mobile node and the home agent.

   After this, the mobile node sends to the correspondent node two
   messages in parallel: a Home Test Init message and a Care-of Test
   Init message. The Home Test Init message (2) is tunneled to the
   mobile node's home agent, and forwarded on to the correspondent node.
   The Home Test Init message includes a random Home Init Cookie. The
   Home Init Cookie will be returned by the correspondent node in the
   Home Test message. Both the Home Test Init message and the Home Test
   message are protected by IPsec on the path between the mobile node
   and the mobile node's home agent. They are unprotected on the path
   between the mobile node's home agent and the correspondent node. On
   the latter path, a malicious node may potentially eavesdrop on the
   Home Init Cookie and return it in a spoofed Home Test message. For
   this reason, having to return the cookie restricts the sender of the
   Home Test message to the path between the mobile node's home agent
   and the correspondent node. The mobile node considers this a
   sufficient proof that the Home Test message was generated by the
   correspondent node itself.

   The Care-of Test Init message (3) does not go through the mobile
   node's home agent. It takes the direct path to the correspondent
   node. The Care-of Test Init message includes a random Care-of Init
   Cookie. The Care-of Init Cookie will be returned by the correspondent
   node in the Care-of Test message. Both the Care-of Test Init and the
   Care-of Test messages are not protected by IPsec. A malicious node
   may potentially eavesdrop on the Care-of Init Cookie and return it in
   a spoofed Care-of Test message. For this reason, having to return the
   cookie restricts the sender of the Care-of Test message to the path
   between the mobile node and the correspondent node. The mobile node
   considers this a sufficient proof that the Care-of Test message was
   generated by the correspondent node itself.

   When the home agent receives the Binding Update message, it registers
   the mobile node's new care-of address. If the home agent maintains an
   IPsec tunnel to the mobile node, it also updates the corresponding
   security association to the new care-of address [2]. The home agent
   sends back to the mobile node a Binding Acknowledgement message (4)
   to indicate successful care-of-address registration. The Binding
   Acknowledgement message is authenticated by means of an IPsec
   security association between the mobile node and the home agent.

   When the correspondent node receives the Home Test Init message, it
   sends back to the mobile node a Home Test message (5). The Home Test
   message is directed to the mobile node's home address, hence passes



Vogt, Ed., et al.        Expires August 4, 2004                 [Page 7]

Internet-Draft           Early Binding Updates             February 2004


   the mobile node's home agent. The Home Test message contains a Home
   Keygen Token, a Home Nonce Index, and the Home Init Cookie copied
   from the Home Test Init message. The Home Keygen Token will be used
   by the mobile node when producing the Binding Management Key, as
   described below. The Home Nonce Index identifies a random value based
   on which the correspondent node has computed the Home Keygen Token.
   The mobile node will include the Home Nonce Index in the subsequent
   Binding Update message to allow the correspondent node to reproduce
   the Home Keygen Token.

   Likewise, upon receiving the Care-of Test Init message, the
   correspondent node sends back to the mobile node a Care-of Test
   message (6). The Care-of Test message is directed to the mobile
   node's new care-of address, hence does not pass the mobile node's
   home agent. The Care-of Test message contains a Care-of Keygen Token,
   a Care-of Nonce Index, and the Care-of Init Cookie copied from the
   Care-of Test Init message. The Care-of Keygen Token will be used by
   the mobile node when producing the Binding Management Key, as
   described below. The Care-of Nonce Index identifies a random value
   based on which the correspondent node has computed the Care-of Keygen
   Token. The mobile node will include the Care-of Nonce Index in the
   subsequent Binding Update message to allow the correspondent node to
   reproduce the Care-of Keygen Token.

   The mobile node uses the Home Keygen Token and the Care-of Keygen
   Token to produce a secret key, the Binding Management Key, shared
   with the correspondent node. The Binding Management Key is a one-way
   hash on the concatenation of the Home Keygen Token and the Care-of
   Keygen Token.

   The mobile node then generates a Binding Update message (7) to be
   sent to the correspondent node. The Binding Update message contains a
   message-authentication code produced with the Binding Management Key.
   It also contains the Home Nonce Index and the Care-of Nonce Index.
   The mobile node may request the correspondent node to return a
   Binding Acknowledgement message by raising the A-flag in the Binding
   Update message. A conservative mobile node would wait for the Binding
   Acknowledgement message before using its new care-of address. An
   optimistic mobile node would start using its new care-of address as
   soon as having dispatched the Binding Update message.

   When the correspondent node receives the Binding Update message, it
   can reproduce the Home Keygen Token and the Care-of Keygen Token with
   the help of the two nonce indices. The tokens, in turn, allow the
   correspondent node to reproduce the Binding Management Key. The
   correspondent node can then compute what the message-authentication
   code in the Binding Update message should look like. If the result
   matches the message-authentication code in the Binding Update



Vogt, Ed., et al.        Expires August 4, 2004                 [Page 8]

Internet-Draft           Early Binding Updates             February 2004


   message, the correspondent node can assume two things. First, the
   mobile node must have received the Home Keygen Token in order to
   construct the Binding Management Key with which the
   message-authentication code was produced. Therefore, the mobile node
   is the legitimate owner of the home address with high probability,
   since the Home Keygen Token was sent, as part of the Home Test
   message, to the mobile node's home address. Second, the mobile node
   must have received the Care-of Keygen Token in order to construct the
   Binding Management Key. Hence, the mobile node is apparently
   reachable through the new care-of address, since the Care-of Keygen
   Token was sent, as part of the Care-of Test message, to the mobile
   node's care-of address. Beyond this, the message-authentication code
   validates the Binding Update message's integrity.

   Provided that the message-authentication code coming along with the
   Binding Update message is correct, the correspondent node creates a
   binding-cache entry with the mobile node's new care-of address. The
   correspondent node uses the mobile node's new care-of address as soon
   as the binding-cache entry is in place. In case the A-flag in the
   Binding Update message is set, the correspondent node sends back to
   the mobile node a Binding Acknowledgement message (8) to indicate
   successful care-of-address registration.



4. Early Binding Updates

   In this section, we specify the procedure of Early Binding Updates,
   our proposed modification of the standard binding-update procedure.

   Early Binding Updates evade the latency of the two address tests
   associated with a standard binding update. For this, the two address
   tests are temporally decoupled. A mobile node executes a home-address
   test whenever a handover is imminent. If handovers cannot be
   anticipated, the mobile node may periodically repeat the home-address
   test. Either way, the mobile node has at hand a fresh Home Keygen
   Token when it changes its point of network attachment, and it does
   not need to wait for a lengthy home-address test during the binding
   update. The care-of-address test is performed after having signaled
   the new care-of address to the correspondent node, and in parallel
   with sending data to and from the new care-of address. [1] suggests
   running both tests in parallel and after a handover. However, the
   mobile node may trigger a home-address test before it moves without
   violating the protocol procedure.

   We introduce two new messages: an Early Binding Update message and an
   Early Binding Acknowledgement message. The mobile node sends to the
   correspondent node an Early Binding Update message when it wants to



Vogt, Ed., et al.        Expires August 4, 2004                 [Page 9]

Internet-Draft           Early Binding Updates             February 2004


   register a new care-of address without yet having accomplished a
   care-of-address test. The mobile node may request the correspondent
   node to return an Early Binding Acknowledgement message. All messages
   of the standard binding-update procedure remain unchanged and retain
   their original meaning. Hence, a mobile node may initiate an Early
   Binding Update without knowledge of whether or not the correspondent
   node supports this. In case the correspondent node does not support
   Early Binding Updates, the binding update is automatically reduced to
   the standard procedure.

   We provide a detailed specification of Early Binding Updates in
   Section 4.1. We elaborate on the concurrent care-of-address test in
   Section 4.2. In Section 4.3, we discuss the special case of
   registering a care-of address without having done a home-address test
   in advance.


4.1 Protocol Specification

   This section provides a detailed specification of Early Binding
   Updates. The procedure is summarized in Figure 2.

   A mobile node triggers a home-address test, steps (1) and (2) in
   Figure 2, whenever a handover is imminent. If handovers cannot be
   anticipated, the mobile node may periodically repeat the home-address
   test. Either way, the mobile node has at hand a fresh Home Keygen
   Token when it changes its point of network attachment. The Home Test
   Init and Home Test messages used for an Early Binding Update are the
   same as the ones used for a standard binding update.

   The time after which the mobile node repeats the home-address test
   should be conservatively determined as the minimum time,
   MAX_TOKEN_LIFETIME [1], a token is expected to be valid.
   Alternatively, one might consider adding a Lifetime option to the
   Home Test message to explicitly indicate the time after which the
   Home Keygen Token becomes expired. The Lifetime option could help the
   mobile node determine when to initiate the next home-address test.
   The introduction of a new option would not interfere with Mobile IPv6
   implementations that do not support Early Binding Updates. The new
   option would simply be ignored and skipped by a node that does not
   recognize the option. See section 6.1.5 of [1] for details on this.

   The Home Test Init and Home Test messages are typically protected by
   an IPsec tunnel between the home agent and the mobile node [2]. The
   home agent must update the corresponding security association to the
   mobile node's new care-of address when the mobile node changes its
   point of network attachment. With Early Binding Updates, the
   care-of-address change does not affect a home-address test, because



Vogt, Ed., et al.        Expires August 4, 2004                [Page 10]

Internet-Draft           Early Binding Updates             February 2004


   the home-address test is performed before the mobile node moves. This
   is a difference to a standard binding update, where a home agent must
   update the security association when it receives a Binding Update
   message from the mobile node. Otherwise, the Home Test message could
   not be delivered back to the mobile node through the IPsec tunnel
   [2].


        Mobile Node            Home Agent        Correspondent Node

              Home Test Init (1)
             |-------------------->|-------------------->|

              Home Test (2)
             |<--------------------|<--------------------|

           ~~~~~ [Handover]

              Binding Update (3)
             |-------------------->|

              Early Binding Update (4)
             |------------------------------------------>|

              Care-of Test Init (5)
             |------------------------------------------>|

              Binding Acknowledgement (6)
             |<--------------------|

              Early Binding Acknowledgement (7)
             |<------------------------------------------|

              Care-of Test (8)
             |<------------------------------------------|

              Binding Update (9)
             |------------------------------------------>|

              Binding Acknowledgement (10)
             |<------------------------------------------|

                     Figure 2: Early Binding Update


   When the mobile node detects that it has moved to a different
   network, it configures a new care-of address. The mobile node then
   sends to its home agent a Binding Update message (3). The Binding



Vogt, Ed., et al.        Expires August 4, 2004                [Page 11]

Internet-Draft           Early Binding Updates             February 2004


   Update message informs the home agent about the mobile node's new
   care-of address. It is authenticated by means of an IPsec security
   association between the mobile node and the home agent.

   Having sent the Binding Update message to its home agent, the mobile
   node produces an Early Binding Management Key, which is a one-way
   hash on the Home Keygen Token from the most recently received Home
   Test message. The mobile node then generates an Early Binding Update
   message (4) to be sent to the correspondent node and to be
   authenticated with the Early Binding Management Key. The Early
   Binding Management Key does not incorporate a Care-of Keygen Token as
   the Binding Management Key used for a standard binding update does.
   However, since the Care-of Keygen Token is irrelevant for
   "authentication" purposes, but proves that some node can be reached
   given its care-of address, it stands to reason that the Early Binding
   Management Key is sufficient for authenticating the Early Binding
   Update message. The mobile node will provide proof of its
   reachability at the new care-of address at a later stage, when it
   sends to the correspondent node a standard Binding Update message.
   The mobile node will then need to generate an additional, standard
   Binding Management Key on the basis of both the Home Keygen Token and
   the Care-of Keygen Token. Note that [1] uses a key equivalent to the
   Early Binding Management Key when deleting an existing binding-cache
   entry. See section 5.2.5 of [1] for details on this.

   The Early Binding Update message contains a message-authentication
   code and the Home Nonce Index copied from the most recently received
   Home Test message. There are two differences between the Early
   Binding Update message and the Binding Update message used during a
   standard binding update. First, the message-authentication code in
   the Early Binding Update message is produced with the Early Binding
   Management Key, which does not incorporate a Care-of Keygen Token.
   Second, the Early Binding Update message does not contain a Care-of
   Nonce Index. Note that [1] uses a message similar to the Early
   Binding Update message when deleting an existing binding-cache entry.
   See sections 6.1.7 and 6.2.6 of [1] for details on this. The mobile
   node may request the correspondent node to return an Early Binding
   Acknowledgement message by raising the A-flag in the Early Binding
   Update message. A conservative mobile node would wait for the Early
   Binding Acknowledgement message before using its new care-of address.
   An optimistic mobile node would start using its new care-of address
   as soon as having dispatched the Early Binding Update message.
   Assuming that no packet reordering occurs on the path between the
   mobile node and the correspondent node, the Early Binding Update
   message will come in at the correspondent node ahead of all data
   packets which the mobile node has sent from its new care-of address.
   Whether conservative or optimistic, with Early Binding Updates, the
   mobile node can use its new care-of address about one round-trip time



Vogt, Ed., et al.        Expires August 4, 2004                [Page 12]

Internet-Draft           Early Binding Updates             February 2004


   sooner than with standard binding updates. See Section 5 for an
   efficiency analysis.

   The mobile node sends to the correspondent node a Care-of Test Init
   message (5) in parallel with sending the Early Binding Update
   message. The Care-of Test Init message used for an Early Binding
   Update is the same as the one used for a standard binding update.

   When the home agent receives the Binding Update message, it registers
   the mobile node's new care-of address. If the home agent maintains an
   IPsec tunnel to the mobile node, it also updates the corresponding
   security association to the new care-of address [2]. The home agent
   sends back to the mobile node a Binding Acknowledgement message (6)
   to indicate successful care-of-address registration. The Binding
   Acknowledgement message is authenticated by means of an IPsec
   security association between the mobile node and the home agent.

   When the correspondent node receives the Early Binding Update
   message, it can reproduce the Home Keygen Token with the help of the
   Home Nonce Index. The token, in turn, allows the correspondent node
   to reproduce the Early Binding Management Key. The correspondent node
   can then compute what the message-authentication code in the Early
   Binding Update message should look like. If the result matches the
   message-authentication code in the Early Binding Update message, the
   mobile node must have received the Home Keygen Token in order to
   construct the Early Binding Management Key with which the
   message-authentication code was produced. Therefore, the
   correspondent node can assume that the mobile node is the legitimate
   owner of the home address, since the Home Keygen Token was sent, as
   part of the Home Test message, to the mobile node's home address.
   Beyond this, the message-authentication code validates the Early
   Binding Update message's integrity.

   Provided that the message-authentication code coming along with the
   Early Binding Update message is correct, the correspondent node
   creates a tentative binding-cache entry with the mobile node's new
   care-of address. The correspondent node uses the mobile node's new
   care-of address as soon as the binding-cache entry is in place. Thus,
   with Early Binding Updates, the correspondent node can use the mobile
   node's new care-of address about one round-trip time sooner than with
   standard binding updates. See Section 5 for an efficiency analysis.

   Since a care-of-address test still has to be performed for the mobile
   node's new care-of address, the lifetime of the new binding-cache
   entry is limited to TENTATIVE_BINDING_LIFETIME. The lifetime will be
   extended when the correspondent node receives a standard Binding
   Update message from the mobile node. See Section 4.2 for details on
   the concurrent care-of-address test. In case the A-flag in the Early



Vogt, Ed., et al.        Expires August 4, 2004                [Page 13]

Internet-Draft           Early Binding Updates             February 2004


   Binding Update message is set, the correspondent node sends back to
   the mobile node an Early Binding Acknowledgement message (7) to
   indicate tentative care-of-address registration.

   When the correspondent node receives the Care-of Test Init message,
   it sends to the mobile node a Care-of Test message (8). The Care-of
   Test message used for an Early Binding Update is the same as the one
   used for a standard binding update.

   The Care-of Test message delivers to the mobile node a Care-of Keygen
   Token. The mobile node uses this Care-of Keygen Token together with
   the Home Keygen Token from the most recently received Home Test
   message to produce a standard Binding Management Key. This Binding
   Management Key is a one-way hash on the concatenation of the Home
   Keygen Token and the Care-of Keygen Token. It is equivalent to the
   Binding Management Key used for a standard binding update.

   The mobile node then generates a standard Binding Update message (9)
   to be sent to the correspondent node. This Binding Update message
   contains a message-authentication code produced with the Binding
   Management Key. It is equivalent to the Binding Update message used
   for a standard binding update. The mobile node may request the
   correspondent node to return a Binding Acknowledgement message by
   raising the A-flag in the Binding Update message.

   When the correspondent node receives the Binding Update message, it
   checks the message's authenticity as described in Section 3. Provided
   that the Binding Update message is properly authenticated, the
   correspondent node extends the lifetime of the mobile node's
   tentative binding-cache entry to the regular lifetime proposed in
   [1]. In case the A-flag in the Binding Update message is set, the
   correspondent node sends back to the mobile node a standard Binding
   Acknowledgement message (10) to indicate successful care-of-address
   registration. This Binding Acknowledgement message is equivalent to
   the one used for a standard binding update.


4.2 Concurrent Care-of Address Tests

   In this section, we elaborate on the concurrent care-of-address test.
   A concurrent care-of-address test is performed after a mobile node
   has signaled to the correspondent node a new care-of address. It runs
   in parallel with sending data to and from the new care-of address.
   The concurrent care-of-address test facilitates data transfer while
   testing a mobile node's reachability. It requires the correspondent
   node to create a tentative binding-cache entry with the mobile node's
   new care-of address before a care-of-address test has been
   accomplished.



Vogt, Ed., et al.        Expires August 4, 2004                [Page 14]

Internet-Draft           Early Binding Updates             February 2004


   Data transfer to and from a yet-unverified care-of address is limited
   to a tentative binding-cache entry's lifetime,
   TENTATIVE_BINDING_LIFETIME. On one hand, this lifetime is thought to
   be long enough to outlast the care-of-address test to be performed
   during that time. On the other hand, the lifetime is thought to be
   short enough to discourage the exploitation of concurrent
   care-of-address tests for flooding attacks.

   When the correspondent node receives a properly authenticated Binding
   Update message from the mobile node, it extends the lifetime of the
   tentative binding-cache entry to the regular lifetime proposed in
   [1]. If the Binding Update message arrives before the binding-cache
   entry expires, data transfer can continue without disruption. If the
   Binding Update message fails to arrive before the binding-cache entry
   expires, the correspondent node must stop sending further data
   packets to the mobile node's new care-of address. Subsequent data
   packets will then be sent to the mobile node's home address. See
   Section 6.2 for a discussion on why this is a feasible modus
   operandi.


4.3 Initial Care-of Address Registration

   In Section 4.1, a mobile node is expected to have acquired a valid
   Home Keygen Token prior to changing its point of network attachment.
   There are scenarios, however, in which this is not a feasible
   assumption. For example, the mobile may be connected to its home link
   before changing its point of network attachment. At home, the mobile
   node does not use Mobile IPv6. It hence does not run a home-address
   test, and it does not acquire a Home Keygen Token, before it moves to
   a foreign link. Also, when the mobile node powers on at a foreign
   link, it does not have a valid Home Keygen Token either. The mobile
   node may even be offline for a while and unable to run the
   home-address test. Any previously obtained Home Keygen Token is
   likely to be expired when the mobile node reconnects to a foreign
   link.

   One may consider letting the mobile node perform a home-address test
   even while being at home. This could accelerate handovers from the
   home link to a foreign link. The Home Test Init and Home Test
   messages would continue to obey to the rules defined in sections 9.4
   and 11.6 of [1], except that they would not have to be tunneled
   between the mobile node and its home agent. Nonetheless, performing a
   home-address test from the home network does not help when a mobile
   node reconnects to a foreign network after an offline period or after
   booting up. Obviously, the mobile node must have a chance to register
   a care-of address with its correspondent node without having acquired
   a Home Keygen Token beforehand.



Vogt, Ed., et al.        Expires August 4, 2004                [Page 15]

Internet-Draft           Early Binding Updates             February 2004


   These observations lead to the following exception: When a mobile
   node wants to register a new care-of address with a correspondent
   node, and the mobile node does not yet know a valid Home Keygen
   Token, the mobile node runs a standard binding update instead of an
   Early Binding Update. When the standard binding update is complete,
   the mobile node can communicate through its new care-of address. The
   mobile node will henceforth trigger a home-address test whenever a
   handover is imminent. If handovers cannot be anticipated, the mobile
   node may periodically repeat the home-address test. Either way, the
   mobile node will have available a fresh Home Keygen Token when it
   changes its point of network attachment the next time so as to apply
   an Early Binding Update then.



5. Efficiency Considerations

   In this section, we consider the impact on efficiency that a binding
   update may have. We examine standard binding updates in Section 5.1,
   and we analyze Early Binding Updates in Section 5.2.


5.1 Standard Binding Updates

   When the mobile node detects that it has moved to a different
   network, it configures a new care-of address. [1] defines that a
   mobile node must do the following steps before it can use the new
   care-of address: First, the mobile node must register the new care-of
   address with its home agent. Second, the home-address test and,
   third, the care-of-address test must be executed. Fourth, the mobile
   node must register the new care-of address with its correspondent
   node.

   Registering the new care-of address with the home agent is a two-way
   message exchange between the mobile node and the mobile node's home
   agent. It consists of a Binding Update message and a Binding
   Acknowledgement message. Let RTT_HA be the round-trip time for the
   Binding Update and Binding Acknowledgement messages. Here, HA means
   "home agent".

   The home-address test is a two-way message exchange between the
   mobile node and the correspondent node. It consists of a Home Test
   Init message and a Home Test message, both of which are tunneled
   between the mobile node and the mobile node's home agent. Let the
   round-trip time for the Home Test Init and Home Test messages be
   RTT_BT. Here, BT means "bidirectional tunneling".

   The care-of-address test is a two-way message exchange between the



Vogt, Ed., et al.        Expires August 4, 2004                [Page 16]

Internet-Draft           Early Binding Updates             February 2004


   mobile node and the correspondent node. It consists of a Care-of Test
   Init message and a Care-of Test message, both of which are relayed on
   the direct path between the mobile node and the correspondent node.
   They do not pass the mobile node's home agent. Let the round-trip
   time for the Care-of Test Init and Care-of Test messages be RTT_RO.
   Here, RO means "route optimization".

   The mobile node may dispatch the Home Test Init and Care-of Test Init
   messages at any time after having sent the Binding Update message to
   the home agent. The mobile node may thus send out all three messages
   virtually in parallel. It takes approximately RTT_HA time until the
   mobile node receives the Binding Acknowledgement message from its
   home agent. The time until the mobile node receives the Home Test
   message from the correspondent node is approximately RTT_BT. Finally,
   it takes approximately RTT_RO time until the Care-of Test message
   arrives at the mobile node. The mobile node must wait for all three
   messages before it can register its new care-of address with the
   correspondent node.

   Registering the new care-of address with the correspondent node is a
   one-way or two-way message exchange between the mobile node and the
   correspondent node. It consists of a Binding Update message and an
   optional Binding Acknowledgement message. The mobile node may request
   the correspondent node to return a Binding Acknowledgement message by
   raising a flag in the Binding Update message. A conservative mobile
   node would wait for the Binding Acknowledgement message before using
   its new care-of address. An optimistic mobile node would start using
   its new care-of address as soon as having dispatched the Binding
   Update message.

   All things considered, a standard binding update's total latency with
   respect to sending data from a new care-of address can be
   approximated by

      STD_LATENCY_SEND_CONSERV = Max (RTT_HA, RTT_BT, RTT_RO) + RTT_RO
      STD_LATENCY_SEND_OPTIMST = Max (RTT_HA, RTT_BT, RTT_RO)

   Here, STD_LATENCY_SEND_CONSERV pertains to a conservative mobile
   node, which waits for the returning Binding Acknowledgement message
   before it uses its new care-of address. STD_LATENCY_SEND_OPTIMST
   pertains to an optimistic mobile node, which uses its new care-of
   address as soon as having dispatched the Binding Update message.

   Whether or not the mobile node waits for the returning Binding
   Acknowledgement message, the correspondent node starts using the
   mobile node's new care-of address upon receiving the mobile node's
   Binding Update message. When the correspondent node switches to the
   new care-of address, it takes another 0.5 RTT_RO time until the first



Vogt, Ed., et al.        Expires August 4, 2004                [Page 17]

Internet-Draft           Early Binding Updates             February 2004


   data packets arrive at the mobile node's new care-of address. Thus, a
   standard binding update's total latency with respect to receiving
   data at a new care-of address can be approximated by

      STD_LATENCY_RECV = Max (RTT_HA, RTT_BT, RTT_RO) + RTT_RO

   If the mobile node has already recently changed its point of network
   attachment, it may reuse its previously acquired Home Keygen Token
   without running another home-address test. In this situation, RTT_BT
   reduces to zero, and Max (RTT_HA, RTT_BT, RTT_RO) = Max (RTT_HA,
   RTT_RO).


5.2 Early Binding Updates

   Moving from one point of network attachment to another involves a
   handover and a binding update. During the handover, the mobile node
   attaches to a new access point, re-authenticates itself, discovers a
   new default router, and configures a new care-of address. During the
   binding update, the mobile node signals to its correspondent node and
   its home agent the new care-of address. More specifically, the mobile
   node runs a home-address test and a care-of-address test, and it
   sends a Binding Update message to both its correspondent node and its
   home agent.

   One might consider three candidate periods during which to execute
   the home-address test and the care-of address test. These candidate
   periods are as follows.

      (1) Before handover
      (2) After handover, but before binding update
      (3) After binding update

   The home-address test is intended to authenticate a node's home
   address. For this reason, the home-address test must be performed at
   either (1) or (2), but cannot be performed at (3). In [1], the
   home-address test is preferably done at (2), but it may also take
   place at (1). Technically, there is nothing that prevents a mobile
   node from initiating the home-address test at (1). The mobile node
   just needs to make sure that the Home Keygen Token from the
   home-address test is still valid at the time the binding update is
   done.

   The care-of-address test is intended to prove that the mobile node is
   reachable at its new care-of address. Therefore, the care-of-address
   test obviously cannot be done at (1). In [1], the care-of-address
   test is done at (2), i.e., it runs in parallel with the home-address
   test. We claim that testing the mobile node's reachability at its new



Vogt, Ed., et al.        Expires August 4, 2004                [Page 18]

Internet-Draft           Early Binding Updates             February 2004


   care-of address may also be done at (3). Data transmission to and
   from the new care-of address may wait or, as with Early Binding
   Updates, start with appropriate restrictions until the mobile node
   has provided proof to the correspondent node that it is reachable at
   its new care-of address.

   With Early Binding Updates, the home-address test is moved to (1),
   and the care-of-address test is moved to (3). The home-address test
   does no longer delay the binding update, because it runs while the
   mobile node still uses a functioning, fully registered care-of
   address. The care-of-address test does no longer delay the binding
   update either, because it runs while the mobile node uses a new,
   tentatively registered care-of address. There are two things that
   remain to be done after a handover: First, the mobile node must
   register the new care-of address with its home agent. Second, the
   mobile node must tentatively register the new care-of address with
   the correspondent node.

   Registering the new care-of address with the home agent is a two-way
   message exchange between the mobile node and the mobile node's home
   agent. It consists of a Binding Update message and a Binding
   Acknowledgement message. Let RTT_HA be the round-trip time for the
   Binding Update and Binding Acknowledgement messages. Here, HA means
   "home agent".

   Tentatively registering the new care-of address with the
   correspondent node is a one-way or two-way message exchange between
   the mobile node and the correspondent node. It consists of an Early
   Binding Update message and an optional Early Binding Acknowledgement
   message. The mobile node may request the correspondent node to return
   an Early Binding Acknowledgement message by raising a flag in the
   Early Binding Update message. Let the round-trip time for the Early
   Binding Update and Early Binding Acknowledgement messages be RTT_RO.
   Here, RO means "route optimization".

   A conservative mobile node would wait for both the Binding
   Acknowledgement message from its home agent and the Early Binding
   Acknowledgement from its correspondent node before using its new
   care-of address. An optimistic mobile node would start using its new
   care-of address as soon as having dispatched the Binding Update and
   Early Binding Update messages.

   All things considered, an Early Binding Update's total latency with
   respect to sending data from a new care-of address can be
   approximated by

      NEW_LATENCY_SEND_CONSERV = Max (RTT_HA, RTT_RO)




Vogt, Ed., et al.        Expires August 4, 2004                [Page 19]

Internet-Draft           Early Binding Updates             February 2004


      NEW_LATENCY_SEND_OPTIMST = 0

   Here, NEW_LATENCY_SEND_CONSERV pertains to a conservative mobile
   node, which waits for both the Binding Acknowledgement message
   returning from its home agent and the Early Binding Acknowledgement
   returning from its correspondent node before it uses its new care-of
   address. NEW_LATENCY_SEND_OPTIMST pertains to an optimistic mobile
   node, which uses its new care-of address as soon as having dispatched
   the Binding Update and Early Binding Update messages.

   Whether or not the mobile node waits for the returning Binding
   Acknowledgement and Early Binding Acknowledgement messages, the
   correspondent node starts using the mobile node's new care-of address
   upon receiving the mobile node's Early Binding Update message. When
   the correspondent node switches to the new care-of address, it takes
   another 0.5 RTT_RO time until the first data packets arrive at the
   mobile node's new care-of address. Thus, an Early Binding Update's
   total latency with respect to receiving data can be approximated by

      NEW_LATENCY_RECV = RTT_RO

   This evaluation shows that an Early Binding Update is about a
   round-trip time faster than a standard binding update. This is true
   even if the mobile node is able to reuse a previously acquired Home
   Keygen Token without running another home-address test. The new
   responsiveness to mobility will be of true benefit for
   delay-sensitive applications.

   Section 4.3 discusses the initial care-of-address registration,
   during which the mobile node does not yet know a valid Home Keygen
   Token. In this situation, the mobile node must perform a standard
   binding update, and there is no efficiency improvement. However, we
   point out that having to resort to a standard binding update is
   limited to only very few scenarios and will rather be an exception.



6. Security Considerations

   In this section, we elaborate on security implications that come
   along with using Early Binding Updates instead of standard binding
   updates. There are two conceptual differences between an Early
   Binding Update and a standard binding update. First, with the Early
   Binding Update, the home-address test is decoupled from the
   care-of-address test, and the Early Binding Management Key used to
   authenticate an Early Binding Update message is produced with the
   Home Keygen Token only. In contrast, the Binding Management Key used
   for a standard binding update is produced with both the Home Keygen



Vogt, Ed., et al.        Expires August 4, 2004                [Page 20]

Internet-Draft           Early Binding Updates             February 2004


   Token and the Care-of Keygen Token. We discuss this matter in Section
   6.1. Second, we propose to execute the care-of-address test in
   parallel with sending data to and from the new care-of address. A
   malicious - yet properly authenticated - node can so wage a flooding
   attack for a limited time. We analyze this issue in Section 6.2. We
   also propose precautions against a flooding attack.

   For a comprehensive taxonomy of mobility-related attacks, we refer to
   the Mobile IPv6 Route Optimization Security Design Background [3].
   The document provides a thorough understanding of what has guided the
   design of the standard binding-update procedure.


6.1 Decoupled Address Tests

   During a standard binding update, a mobile node must accomplish both
   the home-address test and the care-of-address test before it can
   signal to its correspondent node a new care-of address. During an
   Early Binding Update, the home-address test is sufficient to let the
   correspondent node tentatively register a new care-of address. The
   tentative registration becomes a regular one once the mobile node has
   provided proof to the correspondent node that it is reachable at its
   new care-of address.

   Temporally decoupling the home-address test from the care-of-address
   test means separating an authenticity check from a validity check.
   The authenticity check indicates that the mobile node is the
   legitimate owner of the IP address which the mobile node claims to
   own as its home address. The validity check indicates that the mobile
   node is reachable through the IP address which the mobile node wishes
   to register as its care-of address.

   The consequence is this: During the standard binding update, when a
   mobile node's Binding Update message arrives at a correspondent node,
   the correspondent node knows that the message is authentic and that
   the mobile node is reachable through its new care-of address. During
   the Early Binding Update, when a mobile node's Early Binding Update
   message arrives at a correspondent node, the correspondent node can
   trust in the message's authenticity, but it must wait until
   completion of the care-of-address test before it can assume that the
   mobile node is reachable through its new care-of address. The maximum
   time of uncertainty can be configured by the
   TENTATIVE_BINDING_LIFETIME protocol-configuration variable.

   The question is whether separating the two address tests makes
   authentication of binding updates less secure or not. Recall that an
   Early Binding Update message requires only a Home Keygen Token to be
   authenticated, whereas a Binding Update message requires both a Home



Vogt, Ed., et al.        Expires August 4, 2004                [Page 21]

Internet-Draft           Early Binding Updates             February 2004


   Keygen Token and a Care-of Keygen Token. The Home Keygen Token and
   the Care-of Keygen Token are likely to arrive at the mobile node via
   disjoint paths: The former passes through the mobile node's home
   agent, the latter does not. An attacker will thus have a hard time to
   capture both tokens. One might wonder whether the simpler
   authentication of an Early Binding Update message makes Early Binding
   Updates open to eavesdropping and man-in-the-middle attacks. Next, we
   argue that this is not the case.

   Consider an attacker who intends to exploit Early Binding Updates.
   The attacker may want to impersonate the mobile node or the
   correspondent node, sending messages on behalf of one or both of
   them. The attacker may also want to eavesdrop on signaling messages
   in order to gather the information it needs for a later strike. In
   either case, the attacker will have to get active on the home-address
   test, because the home-address test is decisive for the mobile node's
   authenticity. For this, the mobile node needs to be located on the
   path between the mobile node's home agent and the correspondent node,
   because data on the path between the mobile node and its home agent
   is protected by IPsec. The attacker thus has to be somewhere within
   the fixed Internet. Having to tamper with static infrastructure,
   however, is assumed to be an obstacle significant enough to prevent
   many such attacks [3].

   Suppose that, in spite of hurdles, there is an attacker which has
   access to the path between the mobile node's home agent and the
   correspondent node. This attacker is in a position to listen to or
   intercept the Home Test Init and Home Test messages as well as to
   spoof these and other Mobile IPv6 messages. The likely purpose behind
   such an attack is to impersonate the mobile node, to install a false
   binding on behalf of the mobile node, and to divert the mobile node's
   data to an arbitrary location. The point is that, due to the
   attacker's position, such an attack can be accomplished even with the
   standard binding-update procedure. For this, the attacker listens to
   the Home Test message on its way from the correspondent node to the
   mobile node's home agent. It may also send to the correspondent node
   a spoofed Home Test Init message and intercept the returning Home
   Test message. The attacker then sends to the correspondent node a
   spoofed Care-of Test Init message. The attacker will probably use a
   care-of address through which it is reachable, for instance, its own
   current care-of address or its home address. This way, the attacker
   makes sure that it receives the returning Care-of Test message. The
   Care-of Test Init message can be sent from anywhere in the Internet
   unless prevented by ingress filtering. Since ingress filtering is not
   universally employed, sending the spoofed Care-of Test Init message
   is not difficult. Having the Home Test message and the Care-of Test
   message, the attacker can authenticate a fraud Binding Update
   message.



Vogt, Ed., et al.        Expires August 4, 2004                [Page 22]

Internet-Draft           Early Binding Updates             February 2004


   This discussion shows that eavesdropping and impersonation is not
   prevented by taking the disjoint-paths approach of the standard
   binding-update procedure. Instead, access to a particular path within
   the fixed Internet is already enough. We hence believe that an Early
   Binding Update is equally secure than a standard binding update with
   respect to these attacks.


6.2 Concurrent Care-of Address Tests

   A successful care-of-address test provides reasonable assurance to
   the correspondent node that the mobile node is reachable through the
   IP address which the mobile node wishes to register as its care-of
   address. This assurance is a necessary precaution against flooding
   attacks. If no care-of-address test was performed, a malicious mobile
   node could start downloading large volumes of data from multiple
   correspondent nodes and direct these data flows to an arbitrary IP
   address.

   Early Binding Updates allow a mobile node to use a new care-of
   address while the care-of-address test is in progress. This strategy
   reduces the latency associated with a binding update. Concerning
   security against flooding attacks, Early Binding Updates are at a
   minor disadvantage with standard binding updates, because a malicious
   node may exploit the time window during which a correspondent node
   sends data to a yet-unverified care-of address. We propose two ways
   to mitigate this threat.

   One way is to properly configure the lifetime of a tentative
   binding-cache entry. We propose the value,
   TENTATIVE_BINDING_LIFETIME, given in Section 8. In scenarios where
   flooding attacks cannot be ruled out, one should appropriately reduce
   TENTATIVE_BINDING_LIFETIME.

   Another way to mitigate the threat of flooding attacks is to grant
   Early Binding Updates to trusted nodes only. Recall that the
   correspondent node can authenticate a mobile node at the time it
   receives an Early Binding Update message from the mobile node. In
   other words, the correspondent node can assume that the mobile node
   is the legitimate owner of the IP address which the mobile node uses
   as its home address. This, in turn, allows the correspondent node to
   use the mobile node's home address as a criterion for deciding
   whether or not to install a tentative binding-cache entry with the
   mobile node's new care-of address. For instance, the correspondent
   node may be a corporate server which grants Early Binding Updates to
   mobile nodes from the corporate network only.

   Due to the ability to configure, and selectively apply, Early Binding



Vogt, Ed., et al.        Expires August 4, 2004                [Page 23]

Internet-Draft           Early Binding Updates             February 2004


   Updates, we believe that the optimization's disadvantage concerning
   security against flooding attacks is negligible in most practical
   scenarios.



7. Conclusion

   Mobile IPv6 defines two address tests that must be performed before a
   mobile node can register a new care-of address with its correspondent
   node: a home-address test and a care-of-address test. The long
   latency associated with the address tests makes it difficult for
   delay-sensitive applications to hold up service quality during a
   binding update.

   We propose a strategy, Early Binding Updates, to move both address
   test out of the critical period during which a new care-of address
   cannot yet be used. We perform the home-address test before the
   mobile node changes its point of network attachment. We execute the
   care-of-address test in parallel with sending data to and from the
   new care-of address.

   We evaluate Early Binding Updates with respect to the standard
   binding-update procedure. We find that an Early Binding Update can be
   accomplished in half, or less, of the time that a standard binding
   update takes. Moreover, we show that an Early Binding Update is
   nearly equivalent to a standard binding update with respect to
   security, and that it marginally increases the resources required at
   the correspondent node.

   Early Binding Updates are realized as an optional, and fully
   backward-compatible, extension to Mobile IPv6. Early Binding Updates
   use two new messages, both of which have no effect if either
   communication end-point does not support them.



8. Protocol Configuration Variables

   TENTATIVE_BINDING_LIFETIME    3 seconds (default)



References

   [1]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
        IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), June
        2003.



Vogt, Ed., et al.        Expires August 4, 2004                [Page 24]

Internet-Draft           Early Binding Updates             February 2004


   [2]  Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
        Protect Mobile IPv6 Signaling between Mobile Nodes and Home
        Agents", draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in
        progress), July 2003.

   [3]  Nikander, P., "Mobile IP version 6 Route Optimization Security
        Design Background", draft-nikander-mobileip-v6-ro-sec-02 (work
        in progress), December 2003.


Authors' Addresses

   Christian Vogt (Editor and Contact Person)
   Institute of Telematics
   University of Karlsruhe (TH)
   P.O. Box 6980
   76128 Karlsruhe
   Germany

   Phone: +49-721-608-8282
   Fax:   +49-721-388-097
   EMail: chvogt@tm.uka.de
   URI:   http://www.tm.uka.de/~chvogt/


   Roland Bless
   Institute of Telematics
   University of Karlsruhe (TH)
   P.O. Box 6980
   76128 Karlsruhe
   Germany

   Phone: +49-721-608-6413
   Fax:   +49-721-388-097
   EMail: bless@tm.uka.de
   URI:   http://www.tm.uka.de/~bless/















Vogt, Ed., et al.        Expires August 4, 2004                [Page 25]

Internet-Draft           Early Binding Updates             February 2004


   Mark Doll
   Institute of Telematics
   University of Karlsruhe (TH)
   P.O. Box 6980
   76128 Karlsruhe
   Germany

   Phone: +49-721-608-6403
   Fax:   +49-721-388-097
   EMail: doll@tm.uka.de
   URI:   http://www.tm.uka.de/~doll/


   Tobias K’fner
   Institute of Telematics
   University of Karlsruhe (TH)
   P.O. Box 6980
   76128 Karlsruhe
   Germany

   Phone: +49-721-608-8282
   Fax:   +49-721-388-097
   EMail: kuefner@tm.uka.de
   URI:   http://www.tm.uka.de/~kuefner/



























Vogt, Ed., et al.        Expires August 4, 2004                [Page 26]

Internet-Draft           Early Binding Updates             February 2004


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


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

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



Vogt, Ed., et al.        Expires August 4, 2004                [Page 27]

Internet-Draft           Early Binding Updates             February 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

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











































Vogt, Ed., et al.        Expires August 4, 2004                [Page 28]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/