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

Versions: 00

Network Working Group                                            C. Vogt
Internet-Draft                               Univ. of Karlsruhe, Germany
Expires: August 18, 2005                               February 14, 2005


                 Early Binding Updates for Mobile IPv6
            draft-vogt-mobopts-early-binding-updates-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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 18, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   Mobile IPv6 defines a return-routability procedure for secure use of
   route optimization between unacquainted nodes.  The handover latency
   caused by the procedure can significantly impact delay-sensitive
   applications, however.  This document presents an optimization to
   Mobile IPv6 that eliminates the latency.  The optimization is
   realized as an optional, and fully backward-compatible, extension to
   Mobile IPv6.



Vogt                     Expires August 18, 2005                [Page 1]


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Definitions  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1  New Terminology  . . . . . . . . . . . . . . . . . . . . .   5
     2.2  New Message Types  . . . . . . . . . . . . . . . . . . . .   5
     2.3  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.   Optimization Components  . . . . . . . . . . . . . . . . . .   7
     3.1  Optimistic Behavior  . . . . . . . . . . . . . . . . . . .   7
     3.2  Proactive Home Address Tests . . . . . . . . . . . . . . .   8
     3.3  Tentative Correspondent Registrations  . . . . . . . . . .   8
     3.4  Concurrent Care-of Address Tests . . . . . . . . . . . . .   9
     3.5  Proactive Registrations  . . . . . . . . . . . . . . . . .   9
   4.   Protocol . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.   Handling Unverified Care-of Addresses  . . . . . . . . . . .  14
     5.1  Dropping Packets . . . . . . . . . . . . . . . . . . . . .  14
     5.2  Buffering Packets  . . . . . . . . . . . . . . . . . . . .  14
     5.3  Diverted Routing . . . . . . . . . . . . . . . . . . . . .  15
     5.4  Heuristics . . . . . . . . . . . . . . . . . . . . . . . .  15
     5.5  Trusted Communities  . . . . . . . . . . . . . . . . . . .  15
     5.6  Credit-Based Authorization . . . . . . . . . . . . . . . .  15
     5.7  Ingress Filtering  . . . . . . . . . . . . . . . . . . . .  16
   6.   Performance Analysis . . . . . . . . . . . . . . . . . . . .  16
     6.1  Basic Mobile IPv6  . . . . . . . . . . . . . . . . . . . .  17
     6.2  Optimistic Behavior  . . . . . . . . . . . . . . . . . . .  18
     6.3  Early Binding Updates  . . . . . . . . . . . . . . . . . .  19
   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  21
     7.1  Authentication . . . . . . . . . . . . . . . . . . . . . .  21
     7.2  Reachability . . . . . . . . . . . . . . . . . . . . . . .  21
   8.   Conclusion . . . . . . . . . . . . . . . . . . . . . . . . .  22
   9.   Protocol Constants . . . . . . . . . . . . . . . . . . . . .  23
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  23
     10.1   Normative References . . . . . . . . . . . . . . . . . .  23
     10.2   Informational References . . . . . . . . . . . . . . . .  23
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  25
   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  25
        Intellectual Property and Copyright Statements . . . . . . .  26














Vogt                     Expires August 18, 2005                [Page 2]


Internet-Draft            Early Binding Updates            February 2005


1.  Introduction

   Mobility Support in IPv6 (RFC 3775 [1]), or Mobile IPv6, enables
   mobile nodes to change their point of IP attachment without loosing
   active communications connections.  It uses two IP addresses per
   mobile node in order to separate localization semantics from
   identification semantics:  A transient "care-of address" routes to
   the mobile node"s current point of IP attachment.  A static "home
   address" serves as an identifier at stack layers above IP.  The
   mobile node configures a new care-of address when it detects that it
   has moved to a different subnet.  The home address remains stable
   across movements.

   Correspondent nodes can send packets for the mobile node to either
   address.  When they send them to the care-of address, the packets
   reach the mobile node directly.  When they send them to the home
   address, they will be routed to the mobile node's "home network".
   There, a non-mobile "home agent" intercepts the packets, encapsulates
   them, and tunnels them to the care-of address.  Vice versa, the
   mobile node may send its packets from the care-of address directly to
   the correspondent node, or it may tunnel them to the home agent to
   have them sent from the home address.  Relaying packets through the
   home agent is called "bidirectional tunneling", sending them directly
   "route optimization".

   Route optimization has the appealing property that it saves a lot of
   routing overhead compared to bidirectional tunneling.  Experts deem
   this more and more important, in particular in the IPv6 Internet, due
   to the increasing number of mobile nodes.  However, route
   optimization bears a security challenge, since two communication
   peers do not necessarily have to be acquainted.  One may think, e.g.,
   of a mobile user streaming a news video from CNN.  It is non-trivial
   to secure mobility-related signaling between these peers.  [11] gives
   a detailed account on the Mobile IPv6 security design.  Relevant to
   this document are the following two questions.

   o  When the correspondent node receives a command to redirect node
      X's packets, how can it be sure that it is X itself, rather than a
      malicious third node, who has send this command?
   o  Assuming that the correspondent node can somehow identify X as the
      originator of a certain redirection request, how can it rely on X
      actually being present at the IP address to which packets are to
      be redirected?

   The first question raises an authentication issue, the second points
   to the lack of trust between the peers.  There are a variety of
   possibilities how one could have realized authentication in Mobile
   IPv6.  Amongst them are certificate technology [8], DNSSEC [7], or



Vogt                     Expires August 18, 2005                [Page 3]


Internet-Draft            Early Binding Updates            February 2005


   crypto-based identifiers [14][10].  But a desire to be independent
   from a global, trusted infrastructure as well as IPR restrictions
   paved the way for a different strategy: return routability.  Testing
   "return routability" of a node X at an IP address A means to check
   whether X can receive packets sent to A.  Since Mobile IPv6 uses the
   home address as an identifier and the care-of address as a locator,
   checking return routability of the former can authenticate a mobile
   node, and checking return routability of the latter can validate a
   mobile node's presence at the new destination for redirected packets.

   The advantages of the return-routability procedure are low processing
   and state requirements as well as an infrastructural independence.  A
   vulnerability to on-path attackers is acceptable because the issue
   with on-path attacks already applies to the non-mobile Internet and
   is not mobility-specific (cf.  [11]).  A disadvantage of the
   return-routability procedure is its high latency, though:  Both a
   home-address test and a care-of-address test are potentially executed
   over very long distances, so interactive real-time applications can
   be significantly impacted by their delay.

   This document proposes an optional extension to Mobile IPv6, Early
   Binding Updates, which eliminates the delays caused by the
   return-routability procedure.  The improvement is achieved by doing a
   home-address test proactively before a handover, allowing a mobile
   node to optimistically pursue its home and correspondent
   registrations in parallel, tentatively registering a new care-of
   address immediately after movement detection and IPv6 Address
   Autoconfiguration (i.e., without doing the care-of-address test
   first), and postponing the care-of-address test to a time where usual
   communications have already been resumed through the new care-of
   address.  This reduces the critical handover latency from two
   round-trip times to one.  Early Binding Updates also allow the mobile
   node to proactively register a new care-of address with its home
   agent and correspondent node before moving to that care-of address.
   This requires an external mechanism to notify the mobile node, at its
   old point of IP attachment, about an imminent handover and a valid
   new care-of address [12].  Proactive registrations can eliminate
   Mobile IPv6 handover signaling entirely.

   Early Binding Updates for Mobile IPv6 were first presented at the
   59th IETF meeting in Seoul, Republic of Korea, in February 2004.



2.  Definitions

   This document uses the terminology and message types specified in RFC
   3775.  It additionaly introduces a small set of new terminology and



Vogt                     Expires August 18, 2005                [Page 4]


Internet-Draft            Early Binding Updates            February 2005


   defines two new message types.  Some abbreviations are used for the
   sake of brevity and preciseness throughout the document.  This
   section summarizes any terminology, message types, and acronyms not
   already mentioned in RFC 3775.


2.1  New Terminology

   Proactive Home Address Test
      A home-address test initiated by a mobile node before handover,
      the intention being to have a valid Home Keygen Token already
      available during the critical handover period (cf.  Section 3).

   Tentative Correspondent Registration
      A correspondent registration with limited lifetime that a mobile
      node conducts before it initiates a standard correspondent
      registration.  A tentative correspondent registration does not
      provide evidence to a correspondent node that the mobile node is
      indeed reachable at the registered care-of address (cf.
      Section 3).

   Unverified Care-of Address
      A care-of address registered by means of a tentative correspondent
      registration.  A mobile node's reachability at an unverified
      care-of address is not known to a correspondent node, because no
      care-of-address test has (yet) been done.

   Verified Care-of Address
      A care-of address registered by means of a standard correspondent
      registration.  A mobile node's reachability at a verified care-of
      address has been determined through a care-of-address test.

   Concurrent Care-of Address Test
      A care-of-address test for an unverified care-of address executed
      subsequent to a tentative correspondent registration.  The
      unverified care-of address is already in use during the concurrent
      care-of-address test (cf.  Section 3).

   Proactive Registration
      A method by which a mobile node may register a new care-of address
      before moving to that care-of address (cf.  Section 3).


2.2  New Message Types







Vogt                     Expires August 18, 2005                [Page 5]


Internet-Draft            Early Binding Updates            February 2005


   Early Binding Update
      A mobile node sends an Early Binding Update message to a
      correspondent node for tentative correspondent registration.

   Early Binding Acknowledgement
      A correspondent node may return an Early Binding Acknowledgement
      message to a mobile node in response to an Early Binding Update
      message.


2.3  Acronyms

   HoTI
      The Home Test Init message that a mobile node sends to a
      correspondent node during the home-address test.

   HoT
      The Home Test message that a correspondent node returns to a
      mobile node during the home-address test.

   CoTI
      The Care-of Test Init message that a mobile node sends to a
      correspondent node during the care-of-address test.

   CoT
      The Care-of Test message that a correspondent node returns to a
      mobile node during the care-of-address test.

   BU[HA]
      The Binding Update message that a mobile node sends to its home
      agent during home registration.

   BA[HA]
      The Binding Acknowledgement message that a home agent returns to a
      mobile node during home registration.

   BU[CN]
      The Binding Update message that a mobile node sends to a
      correspondent node during correspondent registration.

   BA[CN]
      The Binding Acknowledgement message that a correspondent node
      returns to a mobile node during correspondent registration.

   EBU






Vogt                     Expires August 18, 2005                [Page 6]


Internet-Draft            Early Binding Updates            February 2005


      The Early Binding Update message that a mobile node sends to a
      correspondent node during tentative correspondent registration.

   EBA
      The Early Binding Acknowledgement message that a correspondent
      node may return to a mobile node during tentative correspondent
      registration.

   RTT[MN,HA]
      One round-trip time between a mobile node and its home agent.

   RTT[MN,CN]
      One round-trip time between a mobile node and a correspondent
      node, measured on the direct path between the peers.

   RTT[MN,HA,CN]
      One round-trip time between a mobile node and a correspondent node
      for messages bidirectionally routed through the mobile node's home
      agent.



3.  Optimization Components

   Early Binding Updates for Mobile IPv6 have four basic optimization
   components: optimistic behavior, proactive home-address tests,
   tentative correspondent registrations, and concurrent care-of-address
   test.  Optionally, proactive registrations may be used in addition.
   This section introduces the optimization components.


3.1  Optimistic Behavior

   RFC 3775 allows a mobile node to pursue a return-routability
   procedure in parallel with the corresponding home registration.  This
   behavior is "optimistic" in the sense that the return-routability
   procedure would have been accomplished in vain should the home
   registration fail or be rejected.  Conservative Mobile IPv6
   implementations for mobile nodes execute the home registration and
   the return-routability procedure in sequence.  E.g., the current
   version of Kame Shisa [16] activates its return-routability state
   machine upon reception of a BA{HA}.

   Optimistic behavior may be applied without Early Binding Updates, but
   not vice versa.  Early Binding Updates go one step further in that
   they allow the mobile node to not only conduct the return-routability
   procedure, but also a tentative correspondent registration (see
   below) simultaneously with the home registration.



Vogt                     Expires August 18, 2005                [Page 7]


3.2  Proactive Home Address Tests

   RFC 3775 defines a lifetime of 3.5 minutes for Home and Care-of
   Keygen Tokens.  This feature allows a mobile node to authenticate
   itself during a handover based on a Home Keygen Token that it has
   already acquired before the handover.  Such a proactive home-address
   test saves a possibly long round-trip time through the home agent
   during the critical handover period.

   There are essentially two ways to implement proactive home-address
   tests.  If the mobile node's local link layer provides a trigger that
   tells the mobile node about an imminent handover, the mobile node can
   invoke proactive home-address tests on a just-in-time basis.
   Alternatively, the mobile node may repeat the proactive home-address
   test whenever the most recently obtained Home Keygen Token is about
   to expire.  Either way, the mobile node has a valid token at hand
   when a handover occurs.

   A mobile node should also do proactive home-address tests while it
   stays at home.  This allows the mobile node to apply Early Binding
   Updates when leaving the home network.  The Binding Update List
   contains information about the state of a home-address test, so the
   mobile node may keep existing and create new entries in the Binding
   Update List when at home, just as it does when not at home.  Such
   entries would have the current care-of address set to the mobile
   node's home address.

   Implementations must not confuse Binding Update List entries for
   which a correspondent (de-)registration is pending or still to be
   initiated from those for which (de-)registration is already complete.
   In particular should the mobile node not automatically initiate
   (de-)registration when receiving the HoT from a proactive
   home-address test.


3.3  Tentative Correspondent Registrations

   According to RFC 3775, a mobile node may initiate the
   return-routability procedure for a planned correspondent registration
   while it is waiting for a BA[HA] acknowledging successful home
   registration.  However, the mobile node must receive this BA[HA]
   before it can register with the correspondent node.  Early Binding
   Updates allow the mobile node to also pursue a tentative
   correspondent registration while waiting for the BA[HA].  A tentative
   correspondent registration has a lifetime just long enough to bridge
   the expected duration of the remaining registration procedure.  It is
   authenticated with the Home Keygen Token from the most recent
   proactive home-address test, but lacks proof of a successful
   care-of-address test.  The mobile node replaces a tentative



Vogt                     Expires August 18, 2005                [Page 8]


Internet-Draft            Early Binding Updates            February 2005


   correspondent registration with a standard one later during the
   message exchange.  A tentatively registered care-of address is called
   "unverified", and a care-of address registered the standard way is
   called "verified".

   The correspondent node stops sending further packets to an old
   care-of address once the mobile node has tentatively registered a
   new, unverified care-of address.  It accepts route-optimized packets
   that the mobile node sends from the unverified care-of address from
   that time on.  However, whether or not the correspondent node sends
   data packets to the unverified care-of address depends on its local
   policies.  Section 5 discusses a range of possible policies that the
   correspondent node may apply in different scenarios.


3.4  Concurrent Care-of Address Tests

   RFC 3775 requires a mobile node to support a correspondent
   registration with proof of its reachability at the new care-of
   address.  Early Binding Updates allow the mobile node to tentatively
   register an unverified care-of address without such evidence, and to
   make up for the care-of-address test after data communications have
   been resumed.  The mobile node affects a standard correspondent
   registration subsequent to this concurrent care-of-address test,
   making the unverified care-of address a verified one.


3.5  Proactive Registrations

   It is conceivable that external mechanisms assist a mobile node
   before handover in learning a valid care-of address for the new link
   [12].  This allows the mobile node to register the new care-of
   address with its home agent and, tentatively, with its correspondent
   node while it is still connected to the old link.  The mobile node
   initiates a concurrent care-of-address test as soon as it arrives at
   the new link.  It then proceeds with a standard correspondent
   registration.  Proactive home and correspondent registrations are an
   optional feature of Early Binding Updates.



4.  Protocol

   This section describes the Mobile IPv6 registration procedure when
   optimized with Early Binding Updates.  Note that a mobile node may
   wish to do route optimization with more than one correspondent node
   at a time.  In this case, the mobile node needs to run a separate
   correspondent registration with each of them.  For the sake of



Vogt                     Expires August 18, 2005                [Page 9]


Internet-Draft            Early Binding Updates            February 2005


   simplicity, it is assumed henceforth that there is only a single
   correspondent node.  Figure 1 illustrates the optimized protocol.


            Mobile Node     Home Agent   Correspondent Node
                 |               |               |
                 |=HoTI=========>|-HoTI--------->|
                 |               |               |
                 |<==========HoT=|<----------HoT-|
                 |               |               |
        Handover ~               |               |
                 |-BU[HA]------->|               |
     Use new CoA |-EBU-------------------------->| Use unverified CoA
                 |-CoTI------------------------->|
                 |               |               |
                 |<-------BA[HA]-|               |
                 |<--------------------------EBA-|
                 |<--------------------------CoT-|
                 |               |               |
                 |-BU[CN]----------------------->| Use verified CoA
                 |               |               |
                 |<-----------------------BA[CN]-|
                 |               |               |


      Figure 1: Registration Procedure with Early Binding Updates


   The mobile node seeks to have a fresh Home Keygen Token acquired
   prior to any handover.  It does so by initiating the home-address
   test in a proactive way.  The test may run periodically whenever the
   current Home Keygen Token is about to expire.  According to RFC 3775,
   tokens are valid for 3.5 minutes (MAX_TOKEN_LIFETIME [1]), so the
   interval between successive proactive home-address tests should be a
   little bit less (HOME_ADDR_TEST_INTERVAL, cf.  Section 9).
   Alternatively, the mobile node's local link layer may provide a
   trigger indicating when a handover is about to happen.  The mobile
   node may do the proactive home-address test right in time in this
   case.

   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 three messages back to back:  a BU[HA] to its home agent, and
   an EBU and a CoTI to the correspondent node.  The BU[HA] initiates
   the home registration, which uses the same messages and proceeds in
   exactly the same way as specified in RFC 3775.  The EBU is a request
   for a tentative registration at the correspondent node.  It has the
   same syntax as a standard BU[CN], but its authenticator is calculated



Vogt                     Expires August 18, 2005               [Page 10]


Internet-Draft            Early Binding Updates            February 2005


   only with the Home Keygen Token obtained during the most recent
   home-address test.  An EBU is similar to the BU[CN] used during
   deregistration when the mobile node returns to its home network.  It
   is a newmessage introduced by Early Binding Updates.  The CoTI
   initiates the concurrent care-of-address test.  A concurrent
   care-of-address test uses the same messages and follows the same
   procedure as specified in RFC 3775, except that data packets may
   already be exchanged through the new care-of address while the test
   is in progress.

   The home agent processes a received BU[HA] according to RFC 3775,
   binds the mobile node's home address to the new care-of address, and
   sends a BA[HA] back to the mobile node.

   When the correspondent node receives the EBU, it tentatively binds
   the mobile node's home address to the new care-of address.  It labels
   the new care-of address "unverified", because the EBU does not show
   whether the mobile node is indeed reachable at this address.  If the
   A flag is set in the EBU, the correspondent node sends an EBA back to
   the mobile node.  The EBA is syntactically the same as a standard
   BA{CN}.

   The correspondent node may send route-optimized data packets to the
   unverified care-of address from this time on.  Whether or not it does
   so depends on its local policies.  Section 5 discusses various
   policies that the correspondent node may apply.  In any case, the
   correspondent node should not send any further packets to an older
   care-of address of the mobile node.























Vogt                     Expires August 18, 2005               [Page 11]


Internet-Draft            Early Binding Updates            February 2005


            Mobile Node     Home Agent   Correspondent Node
                 |               |               |
    L2-triggered |               |               |
    notification |-BU[HA]------->|               |
                 |=HoTI=========>|-HoTI--------->|
                 |               |               |
                 |<-------BA[HA]-|               |
                 |<==========HoT=|<----------HoT-|
                 |               |               |
                 |-EBU-------------------------->| Use unverified CoA
                 |               |               |
    L3-triggered |<--------------------------EBA-|
        handover ~               |               |
     Use new CoA |-CoTI------------------------->|
                 |               |               |
                 |<--------------------------CoT-|
                 |               |               |
                 |-BU[CN]----------------------->| Use verified CoA
                 |               |               |
                 |<-----------------------BA[CN]-|
                 |               |               |


    Figure 2: Registration Procedure with Early Binding Updates and
                        Proactive Registrations


   The local access network may assist the mobile node in doing
   proactive home and correspondent registrations.  The registration
   procedure is a bit different then, as shown in Figure 2.  Proactive
   registrations require that the mobile node is given a valid care-of
   address for the new link (to which it wants to move) while it is
   still connected to the old link.  The mobile node can so send a
   BU[HA], conduct a proactive home-address test, and send an EBU from
   the old link.  The BU[HA] and EBU have an attached Alternate Care-of
   Address option carrying the new care-of address.  Note that this
   address differs from the source addresses in the messages' IP
   headers.  Moreover, both messages should have the A flag set.  The
   mobile node initiates handover to the new link when it receives the
   returning EBA.  It sends a CoTI as soon as it arrives at the new link
   and proceeds as it would do if proactive registrations did not apply.

   The correspondent node processes an incoming CoTI, and returns a
   Care-of Test message (CoT), in the way described in RFC 3775.

   RFC 3775 requires that the requested lifetime for a correspondent
   registration must be less than or equal to the remaining lifetime of
   the current home registration.  The mobile node provides the former



Vogt                    Expires August 18, 2005               [Page 12]


Internet-Draft            Early Binding Updates            February 2005


   in the EBU and BU[CN]; the home agent defines the latter in the
   BA[HA].  As a consequence, the mobile node does not know the
   home-registration lifetime at the time it sends the EBU.  The
   requested lifetime for a tentative correspondent registration should
   therefore be very short.  Specifically, it must not be greater than
   TENTATIVE_RR_BINDING_LIFETIME (see Section 9).

   The EBA is a confirmation that the correspondent node has tentatively
   registered the mobile node's new care-of address.  The correspondent
   node sends an EBA only if the A flag in the EBU is set.  The mobile
   node should retransmit the EBU only when both an expected EBA and the
   CoT fail to be delivered.  Any retransmission of an EBU message must
   be synchronized with a retransmission of the CoTI, and such
   retransmissions must be subject to the rate limitations for CoTI's
   defined in RFC 3775.

   The mobile node handles an incoming CoT in the way defined in RFC
   3775.  Specifically, the mobile node sends the correspondent node a
   BU[CN], the authenticator of which is calculated with the Care-of
   Keygen Token from the received CoT and the Home Keygen Token from the
   most recently received HoT.

   When the correspondent node receives the BU[CN], it sets the lifetime
   of the binding between the mobile node's home and care-of addresses
   as specified in RFC 3775.  This extends the lifetime from its
   tentative value.  The correspondent node also changes the state of
   the care-of address from "unverified" to "verified".  If the A flag
   in the received BU[CN] is set, the correspondent node sends a BA[CN]
   back to the mobile node.  This concludes the correspondent
   registration from the correspondent node's perspective.

   A received BA[CN] concludes the correspondent registration from the
   mobile node's perspective.  If an expected BA[CN] fails to be
   delivered, the mobile node resends the BU[CN] subject to the
   retransmission limitations specified in RFC 3775.  The mobile node
   should not resend an EBU due to the missing BA, however.

   Handover efficiency is highest when the correspondent node sends
   packets to an unverified care-of address directly, but the
   correspondent node may choose to send them to the home address until
   it receives a BU[CN] from the mobile node (cf.  Section 5).  The
   mobile node must expect to receive the correspondent node's packets
   encapsulated by its home agent from the time it receives the EBA (or
   from the time it sends the EBU in case it does not set the A flag in
   this message) up to when it receives the correspondent node's BA[CN]
   (or shortly after it has sent the BU[CN] in case it does not set the
   A flag in this message).  Reception of an EBA is not required, but
   can reconfirm this expectation.  The mobile node should not consider



Vogt                     Expires August 18, 2005               [Page 13]


Internet-Draft            Early Binding Updates            February 2005


   the encapsulated packets as an indication of a failed correspondent
   registration.  Moreover, the mobile node may route-optimize its
   packets for the correspondent node rather than reverse-tunneling them
   through the home agent.  The correspondent node accepts these packets
   due to the tentative binding between the home address and the
   unverified care-of address.



5.  Handling Unverified Care-of Addresses

   A care-of-address test serves to determine whether a mobile node can
   really receive packets at the care-of address where it claims to be
   reachable.  This reachability check misses from a tentative
   correspondent registration.  There is hence a possibility that a node
   illegitimately redirects packets to a third party, even though the
   lifetime for tentative correspondent registrations is limited to
   TENTATIVE_RR_BINDING_LIFETIME (cf.  Section 9).  The severity of such
   "redirection-based flooding attacks" over conventional flooding
   attacks not so much emanates from packet redirection per se, but
   rather from the enormous potential for flooding amplification:  Not
   the attacker itself, but the correspondent node ends up flooding the
   victim--unknowingly, of course.

   A correspondent node may apply different policies for choosing the
   destination address of data packets that it has to send while the
   recipient's current care-of address is unverified.  This section
   compiles several such policies.  Whether or not a particular one is
   feasible in a given scenarios mainly depends on the level of trust
   between the correspondent node and the mobile node.  In any case must
   the correspondent node stop sending further packets to an old care-of
   address of the mobile node, and it must accept packets that the
   mobile node sends to it from the unverified care-of address.


5.1  Dropping Packets

   Local policies may prohibit the correspondent node to send data
   packets to an unverified care-of address.  The correspondent node may
   simply drop such packets.  It may rely on protocols at stack layers
   above IP to retransmit the lost packets when the care-of address
   becomes verified.


5.2  Buffering Packets

   The correspondent node may buffer packets for a mobile node whoose
   care-of address is unverified.  It can send these packets as soon as



Vogt                     Expires August 18, 2005               [Page 14]


Internet-Draft            Early Binding Updates            February 2005


   the care-of address gets verified.


5.3  Diverted Routing

   The correspondent node may choose to send packets for a mobile node
   to the home address while the care-of address is unverified.  The
   mobile node must expect to receive such packets encapsulated by its
   home agent during handover.  The mobile node may still send
   route-optimized packets for the correspondent node directly instead
   of reverse-tunneling them through the home agent.  It may
   reverse-tunnel the packets, however, if latency differences between
   packets routed through the home agent and those sent directly would
   otherwise cause disruption to the application.


5.4  Heuristics

   The lifetime for tentative correspondent registrations is limited to
   TENTATIVE_RR_BINDING_LIFETIME (cf.  Section 9).  If supplemented with
   a heuristic for misuse detection, this restriction can be a
   sufficient discouragement of malicious packet redirection.  Mobile
   nodes have to authenticate their home addresses during a tentative
   correspondent registration, so an attacker can always be identified
   by means of its home address.  However, some damage from protocol
   misuse may still occur, even if the heuristic is very responsive.
   Reactive punishment of a perpetrator may also have little impact when
   the administrative relationship between the perpetrator and the
   correspondent node is loose or non-existant.


5.5  Trusted Communities

   The correspondent node may use the home address as a criterion for
   deciding whether a particular mobile node belongs to a trusted
   community.  If it can rely on the mobile node's trustworthiness, it
   can send packets to an unverified care-of address of this mobile
   node.  If the mobile node is unknown, the correspondent node ought to
   be more cautious while the care-of address is unverified.  It may
   then drop or buffer the packets, or send them to the mobile node's
   home address.  As an example, this strategy could be used by a
   corporate server which trusts mobile nodes only if they are
   affiliated to its own company.


5.6  Credit-Based Authorization

   As previously mentioned, redirection-based flooding attacks are a



Vogt                     Expires August 18, 2005               [Page 15]


Internet-Draft            Early Binding Updates            February 2005


   particular threat due to their potential for high amplification.
   Malicious redirection would lose its attraction to simpler direct
   flooding attacks if theamplification was by some means inhibited.
   Such is the approach followed by Credit-Based Authorization for
   concurrent care-of-address tests [13].  Here, the correspondent node
   monitors a mobile node's effort for transmission or reception of data
   packets.  It gives credit to the mobile node proportionally to this
   effort.  Packets that the correspondent node sends to an unverified
   care-of address of the mobile node reduce the credit.  The
   correspondent node discontinues sending further route-optimized
   packets when no credit is left.  It usually sends the packets to the
   mobile node's home address instead, but it may apply one of the other
   strategies discussed in this section.

   It is worthwhile to mention that Credit-Based Authorization
   facilitates secure use of Alternate Care-of Address options in
   conjunction with concurrent care-of-address tests.  This allows a
   mobile node to proactively register a new care-of address with its
   correspondent node before a handover, provided that it can anticipate
   the handover and foresee a valid new care-of address through some
   external mechanism.


5.7  Ingress Filtering

   The correspondent node may be aware that ingress filtering [4] is
   active on a certain set of IP addresses.  E.g., these IP addresses
   could be allocated to a trusted operator's network.  The
   correspondent node can then send packets to any unverified care-of
   address from this set without risk and apply a different strategy for
   other unverified care-of addresses.  However, a shortfall of ingress
   filtering is that it only checks a packet's source address.  It hence
   fails when a to-be-registered care-of address different than the
   registration message's source address appears in an Alternate Care-of
   Address option.  Proactive correspondent registrations through
   Alternate Care-of Address options and concurrent care-of-address
   tests are hence not compatible with ingress filtering (cf.
   Section 5.6).



6.  Performance Analysis

   This section evaluates the signaling delays of basic Mobile IPv6
   without optimistic behavior, Mobile IPv6 with optimistic behavior,
   and Mobile IPv6 with Early Binding Updates.  There is explicit
   mentioning of optimistic behavior because many Mobile IPv6
   implementations for mobile nodes do not use this optimization



Vogt                     Expires August 18, 2005               [Page 16]


Internet-Draft            Early Binding Updates            February 2005


   opportunity yet.  Signaling delays are measured from the mobile
   node's perspective, in terms of not being allowed to send and being
   unable to receive.  This document does not yet analyze the efficiency
   of proactive registrations, but future versions will.

   Section 5 discusses a number of strategies for handling unverified
   care-of addresses.  Some of them have implications on handover
   performance.  In this section, it is assumed that the correspondent
   node sends route-optimized packets directly to the mobile node's new,
   unverified care-of address as soon as it receives an EBU.

   Note that the overall handover performance does not depend on Mobile
   IPv6 signaling alone, but also on signaling at other layers of the
   protocol stack.  This includes link-layer authentication [3] and
   attachment procedures [2], movement detection, IPv6 Neighbor
   Discovery [5], as well as Address Autoconfiguration and Duplicate
   Address Detection [6].  This document does not consider these
   additional delays, however, as this would go beyond its scope.  On
   the other hand, delays at other stack layers are independent of
   whether basic Mobile IPv6, optimistic behavior, or Early Binding
   Updates are used.  This makes it feasible to focus on Mobile IPv6
   signaling.


6.1  Basic Mobile IPv6

   This section evalates the signaling delay of basic Mobile IPv6 when
   optimistic behavior is not applied.  I.e., the return-routability
   procedure does not begin until the mobile node has received a BA[HA]
   acknowledging successful home registration.

   RFC 3775 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,
   it must execute the return-routability procedure.  Third, the mobile
   node must register the new care-of address with its correspondent
   node.

   A home registration is an exchange of a BU[HA] and a BA[HA] between
   the mobile node and its home agent.  Let RTT[MN,HA] be the round-trip
   time required for these messages.  The home-address test is an
   exchange of a HoTI and a HoT between the mobile node and the
   correspondent node.  Both of these messages are routed through the
   home agent.  Let their required round-trip time be RTT[MN,HA,CN].
   The care-of-address test is an exchange of a CoTI and a CoT between
   the mobile node and the correspondent node.  These messages are
   transmitted directly between the peers, i.e., they do not
   (necessarily) pass the home agent.  Let the round-trip time that



Vogt                     Expires August 18, 2005               [Page 17]


Internet-Draft            Early Binding Updates            February 2005


   these messages need be RTT[MN,CN].  The mobile node must wait for
   all, the BA[HA], the HoT, and the CoT, before it can register its
   care-of address with the correspondent node.  The correspondent
   registration, in turn, is an exchange of a BU[CN] and an optional
   BA[CN].  However, the mobile node does not need to wait for the
   BA[CN].  It may resume sending route-optimized packets to the
   correspondent node as soon as it has dispatched the BU[CN].  The
   signaling delay observed by the mobile node in terms of packet
   transmission thus amounts to

      LATENCY[SEND] = RTT[MN,HA] + Max (RTT[MN,HA,CN], RTT[MN,CN])

   Given that the end-to-end path through the home agent is typically
   longest, LATENCY[SEND] = RTT[MN,HA] + RTT[MN,HA,CN] holds in most
   cases.

   The correspondent node starts using the mobile node's new care-of
   address once it receives the BU[CN].  It then takes another 0.5
   RTT[MN,CN] time until the first data packet arrives at this address.
   This is independent of whether or not a BA[CN] is transmitted.  Thus,
   the mobile node's observed signaling delay for receiving packets can
   be calculated as

      LATENCY[RECEIVE] = RTT[MN,HA] + Max (RTT[MN,HA,CN], RTT[MN,CN]) +
      RTT[MN,CN]

   which should usually reduce to LATENCY[RECEIVE] = RTT[MN,HA] +
   RTT[MN,HA,CN] + RTT[MN,CN].

   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[MN,HA,CN] reduces to zero, so LATENCY[SEND] = RTT[MN,HA] +
   RTT[MN,CN] and LATENCY[RECEIVE] = RTT[MN,HA] + 2*RTT[MN,CN].


6.2  Optimistic Behavior

   Many Mobile IPv6 implementations for mobile nodes execute a home
   registration and the return-routability procedure in sequence.  E.g.,
   the current version of Kame Shisa [16] activates its
   return-routability state machine upon reception of a BA[HA].
   However, RFC 3775 leaves sufficient room for pursuing the
   return-routability procedure already in parallel with the home
   registration.  This section explicitly considers the performance
   benefit of this optimistic behavior.

   As mentioned previously, the latencies for a home registration, a



Vogt                     Expires August 18, 2005               [Page 18]


Internet-Draft            Early Binding Updates            February 2005


   home-address test, and a care-of-address test are RTT[MN,HA],
   RTT[MN,HA,CN], and RTT[MN,CN], respectively.  RFC 3775 defines that
   the mobile node must wait for all, the BA[HA], the HoT, and the CoT,
   before it can send the BU[CN].  As the mobile node may start sending
   route-optimized packets to the correspondent node right after it has
   dispatched the BU[CN], its observed handover latency for sending
   packets amounts to

      LATENCY[SEND,OPTIMISTIC] = Max (RTT[MN,HA], RTT[MN,HA,CN],
      RTT[MN,CN])

   Given that the end-to-end path through the home agent is typically
   longest, LATENCY[SEND,OPTIMISTIC] = RTT[MN,HA,CN] holds in most
   cases.

   Adding another RTT[MN,CN] propagation delay for the BU[CN] and the
   first data packet sent to the new care-of address yields the observed
   handover latency for receiving packets:

      LATENCY[RECEIVE,OPTIMISTIC] = Max (RTT[MN,HA], RTT[MN,HA,CN],
      RTT[MN,CN]) + RTT[MN,CN]

   which should be LATENCY[RECEIVE,OPTIMISTIC] = RTT[MN,HA,CN] +
   RTT[MN,CN] in most scenarios.

   If the mobile node is able to reuse a previously acquired Home Keygen
   Token due to a handover that occurred just recently, RTT[MN,HA,CN]
   becomes zero, and LATENCY[SEND,OPTIMISTIC] = Max (RTT[MN,HA],
   RTT[MN,CN]) and LATENCY[RECEIVE,OPTIMISTIC] = Max (RTT[MN,HA],
   RTT[MN,CN]) + RTT[MN,CN].


6.3  Early Binding Updates

   This section compares the signaling delay of Mobile IPv6 optimized
   with Early Binding Updates to Mobile IPv6 with optimistic behavior
   alone.

   A proactive home-address test does not affect the Mobile IPv6
   signaling delay because it happens while communications are actively
   ongoing at the mobile node's old IP attachment.  A concurrent
   care-of-address test does not add to the signaling delay either, but
   the reason for this, explained next, is a bit more complicated.  It
   is clear that the mobile node can send throughout the entire test.
   The correspondent node, however, becomes aware of the new care-of
   address only when it receives the EBU, and the EBU is transmitted
   during the concurrent care-of-address test.  So, actually, the
   correspondent node sends to the new care-of address for only half of



Vogt                     Expires August 18, 2005               [Page 19]


Internet-Draft            Early Binding Updates            February 2005


   the test.  On the other hand, the EBU's propagation latency equals
   that of a BU[CN]'s.  The one-way-time loss of the correspondent
   node's packets during the first half concurrent care-of-address test
   is therefore compensated in that the correspondent node can already
   send to the new care-of address during the one-way-time propagation
   of the BU[CN], which is not the case in standard Mobile IPv6.  As a
   consequence, the concurrent care-of-address test can be perceived as
   having no effect on the Mobile IPv6 signaling delay.

   The mobile node sends the BU[HA], the EBU, and the CoTI back to back,
   and it may send route-optimized packets as of then.  Outgoing packets
   can thus be transmitted virtually immediately, and

      LATENCY[SEND,EARLY] = 0

   A tentative correspondent registration consists of an EBU and an
   optional EBA exchanged between the mobile node and the correspondent
   node.  The correspondent node learns the new care-of address through
   the EBU, and it may start sending route-optimized packets to the
   mobile node right then.  The first such packet arrives at the mobile
   node 0.5 RTT[MN,CN] time later.  This is independent of whether or
   not an EBA is transmitted.  Thus, the mobile node's observed
   signaling delay for receiving packets can be calculated as

      LATENCY[RECEIVE,EARLY] = RTT[MN,CN]

   This evaluation shows that Early Binding Updates, when compared to
   Mobile IPv6 with optimistic behavior, typically reduces the signaling
   latency by RTT[MN,HA,CN].  Compared to basic, non-optimistic Mobile
   IPv6, the signaling latency decreases by even RTT[MN,HA] +
   RTT[MN,HA,CN]: one round-trip time for the home registration and
   another for the return-routability procedure.  The improvements are
   RTT[MN,CN] and RTT[MN,HA] + RTT[MN,CN],  respectively, in case the
   mobile node has a fresh-enough Home Keygen Token from a recent
   home-address test which it can reuse.

   There may be situations in which the mobile node does not know a
   valid Home Keygen Token during a handover.  For instance, the mobile
   node may not support proactive home-address tests while attached to
   its home link, so it cannot leverage Early Binding Updates when it
   leaves home.  The mobile node may also be temporarily down or
   disconnected, hence unable to execute proactive home-address tests
   for a while.  In cases like this, the mobile node must perform a
   standard binding update, and there is no efficiency improvement.







Vogt                     Expires August 18, 2005               [Page 20]


Internet-Draft            Early Binding Updates            February 2005


7.  Security Considerations

   Early Binding Updates differ from standard Mobile IPv6 in the way a
   mobile node authenticates itself to a correspondent node, and when it
   provides evidence of its reachability.  This section elaborates on
   security implications that might originate from these differences.


7.1  Authentication

   According to RFC 3775, a mobile node must have acquired valid Home
   and Care-of Keygen Tokens before it can initiate a correspondent
   registration.  This requires the mobile node to execute both the
   home-address test and the care-of-address test before it can notify
   its correspondent node about a new care-of address.  In contrast, the
   home-address test alone is sufficient to tentatively register an
   unverified care-of address when Early Binding Updates are used.  The
   unverified care-of address becomes verified once the mobile node has
   provided proof to the correspondent node that it is indeed reachable
   at this address.

   The question is whether lack of a care-of-address test renders
   authentication through EBU's less secure than authentication through
   BU{CN}'s.  At first glance, it may seem so:  A BU{CN}'s authenticator
   depends on two tokens transmitted via separate paths, so whoever
   generates it must be on the intersection of both paths.  Even if the
   paths happen to coincide are they independent in a sense, because
   only one of them is IPsec-protected between the mobile node and the
   home agent.  The point, however, is that only the Home Keygen Token
   is bound to the mobile node's home address (which is the mobile
   node's identifier in the context of Mobile IPv6).  The Care-of Keygen
   Token can be bound to any address.  In particular may the attacker
   choose an address through which it is itself reachable.  The attacker
   can consequently acquire both tokens once it is in a position to
   intercept a HoT sent to the mobile node's home address.  Due to the
   IPsec tunnel between the mobile node and the home agent, this
   position can only be somewhere on the path between the correspondent
   node and the home agent.  In summary, the Care-of Keygen Token does
   not affect a BU{CN}'s authentication capability.  An EBU is therefore
   as secure as a BU{CN} with respect to authentication.  It is
   worthwhile emphasizing that the EBU is authenticated in just the same
   way as a standard  BU{CN} for deregistration.


7.2  Reachability

   Early Binding Updates allow a mobile node to register a new care-of
   address without yet having shown that it is reachable at that



Vogt                     Expires August 18, 2005               [Page 21]


Internet-Draft            Early Binding Updates            February 2005


   address.  A malicious node could potentially misuse this feature for
   a redirection-based flooding attack against a third party.

   Ingress filtering [4] is usually considered a possible solution to
   this problem.  If deployed close to the mobile node's IP attachment,
   ingress filtering can provide reasonable insurance that an unverified
   care-of address is correct.  The technique has two disadvantages,
   however.  One is that it can provide full protection against address
   spoofing only if it is deployed universally.  As long as some
   operators do not use it, redirection attacks can originate from their
   networks.  Another disadvantage is that ingress filtering checks only
   a packet's IP source address.  As a consequence, ingress filtering
   fails when an EBU or BU{CN} has an Alternate Care-of Address option
   with a care-of address different than the message's source address.
   This makes ingress filtering incompatible with proactive
   correspondent registrations.

   Local policies at the correspondent node must hence be restrictive
   enough to rule out misuse of unverified care-of addresses.  Section 5
   discusses a number of strategies that the correspondent node may
   follow.  It depends on the particular deployment scenario which of
   these strategies applies best.



8.  Conclusion

   Mobile IPv6 uses the return-routability procedure for secure route
   optimization between unacquainted nodes.  The procedure verifies
   whether a mobile node can receive packets at its claimed home and
   care-of addresses.  As these tests are executed during the critical
   handover phase, their latency may have an adverse impact on
   delay-sensitive applications.

   This document proposes an optimization to Mobile IPv6, Early Binding
   Updates, which eliminates the handover delay caused by the
   return-routability procedure.  Early Binding Updates move the
   home-address test to the time before handover, and they postpone the
   care-of-address test to a time when the new care-of address can
   already be used.  The performance of this optimization is analyzed
   and compared to that of standard Mobile IPv6.

   Early Binding Updates additionally allow a mobile node to proactively
   register a new care-of address prior to handover.  This can eliminate
   the entire Mobile IPv6 handover delay.  Proactive registrations
   require assistance from the local access network for IPv6 Neighbor
   Discovery and Duplicate Address Detection.




Vogt                     Expires August 18, 2005               [Page 22]


Internet-Draft            Early Binding Updates            February 2005


   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.

   There is, however, a price to pay for the reduced latency.  First,
   Early Binding Updates require transmission of one or two additional
   messages: an EBU and, optionally, an EBA for confirmation.  Second, a
   mobile node must execute the home-address test periodically unless
   the test can be more efficiently scheduled through link-layer
   notifications.  This generally increases the signaling overhead as
   well.  However, the additional overhead should be worth being spent
   in exchange for the expected performance gain.

   To gather more insight in this regard, Early Binding Updates have
   been implemented based on the Kame-Shisa Mobile IPv6 extension for
   FreeBSD.  The source code is available at [15].  Practical
   performance evaluations will supplement the analytical results shown
   in this document.



9.  Protocol Constants

   Early Binding Updates use the protocol constants and variables
   defined in RFC 3775 [1].  This section summarizes some additional
   protocol constants.

      HOME_ADDR_TEST_INTERVAL               200 seconds
      TENTATIVE_RR_BINDING_LIFETIME          10 seconds




10.  References

10.1  Normative References

   [1]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
        IPv6", RFC 3775, June 2004.

10.2  Informational References

   [2]   Institute of Electrical and Electronics Engineers, "Local and
         Metropolitan Area Networks: Wireless LAN Medium Access Control
         (MAC) and Physical Layer (PHY) Specifications",
         ANSI/IEEE Standard 802.11, R2003, June 2003.




Vogt                     Expires August 18, 2005               [Page 23]


Internet-Draft            Early Binding Updates            February 2005


   [3]   Institute of Electrical and Electronics Engineers, "Local and
         Metropolitan Area Networks: Port-Based Network Access Control",
         IEEE Standard 802.1X, September 2001.

   [4]   Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source
         Address Spoofing", RFC 2827, May 2000.

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

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

   [7]   Eastlake, D., "Domain Name System Security Extensions",
         RFC 2535, March 1999.

   [8]   Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
         Public Key Infrastructure Certificate and Certificate
         Revocation List (CRL) Profile", RFC 3280, April 2002.

   [9]   Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
         Addressing Architecture", RFC 3513, April 2003.

   [10]  Haddad, W., Madour, L., Arkko, J. and F. Dupont, "Applying
         Cryptographically Generated Addresses to Optimize MIPv6
         (CGA-OMIPv6)", Internet-Draft draft-haddad-mip6-cga-omipv6
         (work in progress).

   [11]  Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E.
         Nordmark, "Mobile IP version 6 Route Optimization Security
         Design Background", Internet-Draft draft-ietf-mip6-ro-sec (work
         in progress).

   [12]  Koodli, R., "Fast Handovers for Mobile IPv6",
         Internet-Draft draft-ietf-mipshop-fast-mipv6 (work in
         progress).

   [13]  Vogt, C. and J. Arkko, "Credit-Based Authorization for Mobile
         IPv6 Early Binding Updates",
         Internet-Draft draft-vogt-mobopts-credit-based-authorization
         (work in progress).

   [14]  Montenegro, G. and C. Castelluccia, "Crypto-Based Identifiers
         (CBIDs): Concepts and Applications", ACM Transactions on
         Information and System Security Vol. 7, No. 1, February 2004.

   [15]  "Route Optimization Optimized", Project homepage, available



Vogt                     Expires August 18, 2005               [Page 24]


Internet-Draft            Early Binding Updates            February 2005


         at http://www.tm.uka.de/~chvogt/ro2/.

   [16]  "Kame-Shisa Mobile IPv6 Implementation for FreeBSD", available
         at http://www.mobileip.jp/.


Author's Address

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

   Email: chvogt@tm.uka.de
   URI:   http://www.tm.uka.de/~chvogt/

Appendix A.  Acknowledgements

   For their interest and valuable feedback, the author thanks the MIP6
   and MOBOPTS communities, in particular Jari Arkko, Roland Bless, Mark
   Doll, Francis Dupont, Gregory Daley, James Kempf, Tobias Kuefner,
   Lars Eggert, Nick (Sharkey) Moore, Pekka Nikander, Erik Nordmark,
   Charles Perkins, and Kilian Weniger (listed in alphabetical order).
   Thanks are also due to Keiichi Shima and his colleagues from the
   Kame-Shisa development team.
























Vogt                     Expires August 18, 2005               [Page 25]


Internet-Draft            Early Binding Updates            February 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

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


Acknowledgment

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




Vogt                     Expires August 18, 2005               [Page 26]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/