[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04

Mobility Optimizations                                         W. Haddad
Internet-Draft                                                 L. Madour
Expires: November 4, 2005                                       J. Arkko
                                                       Ericsson Research
                                                               F. Dupont
                                                       GET/ENST Bretagne
                                                             May 3, 2005


 Applying Cryptographically Generated Addresses to Optimize MIPv6 (CGA-
                                OMIPv6)
                    draft-haddad-mip6-cga-omipv6-04

Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 November 4, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This memo suggests a new and enhanced route optimization security
   mechanism for Mobile IPv6 (MIPv6).  The primary motivation for this
   new mechanism is the reduction of signaling load and handoff delay.
   The performance improvement achieved is elimination of all signaling



Haddad, et al.          Expires November 4, 2005                [Page 1]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


   while not moving, and 33% of the per-movement signaling.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Efficiency of Current Protocols  . . . . . . . . . . . . . . .  3
   3.  Overview of CGA  . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
         4.1   Requirements . . . . . . . . . . . . . . . . . . . . .  7
         4.2   Design Rationale . . . . . . . . . . . . . . . . . . .  7
         4.3   Overview of Signaling  . . . . . . . . . . . . . . . .  9
         4.4   Cryptographic Calculations . . . . . . . . . . . . . . 11
         4.5   Simultaneous Movements . . . . . . . . . . . . . . . . 12
   5.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 12
         5.1   The Pre Binding Update Message . . . . . . . . . . . . 12
         5.2   The Pre Binding Acknowledgement Message  . . . . . . . 14
         5.3   The Pre Binding Test Message . . . . . . . . . . . . . 15
         5.4   The CGA Key Option . . . . . . . . . . . . . . . . . . 17
         5.5   The Shared Key Option  . . . . . . . . . . . . . . . . 17
         5.6   The Keep Flow Option . . . . . . . . . . . . . . . . . 18
         5.7   The Extended Sequence Number Option  . . . . . . . . . 19
         5.8   The Signature (SIG) Option . . . . . . . . . . . . . . 20
         5.9   Status Codes . . . . . . . . . . . . . . . . . . . . . 21
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   7.  Performance Considerations . . . . . . . . . . . . . . . . . . 22
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
         9.1   Normative References . . . . . . . . . . . . . . . . . 23
         9.2   Informative References . . . . . . . . . . . . . . . . 24
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 26
       Intellectual Property and Copyright Statements . . . . . . . . 27



















Haddad, et al.          Expires November 4, 2005                [Page 2]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


1.  Introduction

   This document describes a new and enhanced route optimization (RO)
   security mechanism for Mobile IPv6[6], based on the Cryptographically
   Generated Addresses (CGAs) as described in [11].  The main goals of
   this protocol are the reduction of the signaling load and the handoff
   delay times.  In addition, the protocol offers some additional
   security benefits.

   This document is a complete specification of an optional, alternative
   mechanism to the standard scheme, and can be applied independently of
   other specifications.  In particular, it does not depend on ongoing
   research work related to route optimization schemes, although it is
   conceivable that some future enhancements can be applied on top of
   this specification.

   This rest of this document is structured as follows.  Section 2
   discusses the performance of the current Mobile IPv6 route
   optimization mechanisms, and Section 3 introduces the concept of
   CGAs.  Section 4 gives an overview of our new mechanism and describes
   its design rationale.  Section 5 describes detailed message formats.
   Finally, Section 6 and Section 7 analyze the security and performance
   properties of the mechanism.

2.  Efficiency of Current Protocols

   This section discusses the efficiency of the current Mobile IPv6
   route optimization mechanisms.

   When evaluating the impact of signaling on performance, one should
   take into account the whole stack and not inspect just one layer or
   task.  For instance, if the mobile node actually moved, the Mobile
   IPv6 signaling would have to be compared to the link layer signaling,
   access control and authentication signaling, and IPv6 tasks such as
   router discovery, neighbor discovery, and duplicate address
   detection.  Such other signaling introduces delays, in many cases
   significantly larger delays than exists in Mobile IPv6.  In this
   document we ignore these other delays, however, and concentrate on
   making the mobility signaling as efficient as possible.  But given
   this, an improvement of, say, 50% in mobility signaling may become
   just 10% unless other delays are also addressed.  Other optimization
   work is ongoing in other parts of the stack, however.

   The performance of the current route optimization mechanism can be
   evaluated according to its impact on handover delay, the amount of
   bandwidth it uses per movement, the amount of bandwidth it uses when
   not moving, and the overhead it causes for payload traffic.  These
   are discussed in the following:



Haddad, et al.          Expires November 4, 2005                [Page 3]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


   Payload traffic overhead

      The primary reason for using route optimization is to avoid
      routing all traffic through a home agent.  We assume that this
      benefit is significant, particularly when two mobile nodes
      communicate with each other.  However, an overhead is associated
      both with packets sent via bidirectional tunneling (tunnel) and
      directly (options for carrying home addresses).  A more detailed
      analysis of the benefits and drawbacks are outside the scope of
      this document, however, as we concentrate on the signaling aspects
      only.

   Latency

      Basic home registration introduces a latency of zero to one
      roundtrips before payload traffic can flow, depending on which
      direction of traffic is looked at and whether the mobile node
      chooses to wait for an acknowledgement.

      With route optimization, the combined latency is one to three
      roundtrips, depending again on the direction of packets and
      waiting for acknowledgements.

      More specifically, RFC 3775 allows mobile nodes to send data
      packets after having sent the home registration Binding Update.
      (If the Binding Update is lost or packets get reordered, the data
      packets can be lost as well.  But this may happen in any case.)

      Home agents and correspondent nodes can start to send data packets
      once they have sent the Binding Acknowledgement.  The overall
      latency until inbound traffic can start flow to the mobile is
      therefore at least 1.5 roundtrips.

      RFC 3775 assumes also that the home and care-of tests are run in
      parallel.  Some implementations may perform poorly, however.  We
      have seen implementations that do not run the home and care-of
      tests in parallel, resulting in an overall delay of 3.5 to 4
      roundtrips.  But even when parallelism is employed, the latency
      across the two different paths can be different.  When two mobile
      nodes are located close to each other, the home test exchange
      typically takes longer than the rest of the messaging.

   Bandwidth usage upon movement

      As discussed in [12], one full run of the return routability and
      binding update procedures is about 376 bytes.  Assuming relatively
      infrequent movements, for instance, every half hour, this
      corresponds to about 1.7 bits/second average bandwidth usage.



Haddad, et al.          Expires November 4, 2005                [Page 4]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


      The situation changes when more frequent movements are assumed.
      Using a cell size of 100 meters and the speed of 120 km/h, there
      will be one movement every 3 seconds.  This amounts to a constant
      route optimization-related signaling of about 1,000 bits/second.
      This can be compared to a highly compressed voice stream which
      typically have a rate about 10,000 to 30,000 bits/second.

   Bandwidth usage when not moving

      Current specifications require a periodic return routability test
      and the re-establishment of the binding at the correspondent node.
      This results in an average bandwidth of about 7 bits/second, if
      performed every seven minutes as required in RFC 3775.  While this
      is an insignificant bandwidth for nodes that are actually
      communicating, it can still represent a burden for hosts that just
      have the bindings ready for a possible packet but are not
      currently communicating.  This can be problematic for hosts in
      standby mode, for instance.

   In summary, setting up the route optimization requires some signaling
   and causes some latency.  The latency issue is perhaps more critical
   than the amount of signaling.  This is because internet-wide RTTs are
   typically much longer (some hundreds of milliseconds) than desired
   latencies for real-time applications such as voice over IP (tens of
   milliseconds).

3.  Overview of CGA

   As described in [11], a Cryptographically Generated Address (CGA) is
   an IPv6 address, which contains a set of bits generated by hashing
   the IPv6 address owner's public key.  Such feature allows the user to
   provide a "proof of ownership" of its IPv6 address.

   The CGA offers three main advantages: it makes the spoofing attack
   against the IPv6 address much harder and allows to sign messages with
   the owner's private key.  CGA does not require any upgrade or
   modification in the infrastructure.

   The CGA offers a method for binding a public key to an IPv6 address.
   The binding between the public key and the address can be verified by
   re-computing and comparing the hash value of the public key and other
   parameters sent in the specific message with the interface identifier
   in the IPv6 address belonging to the owner.  Note that an attacker
   can always create its own CGA address but he will not be able to
   spoof someone else's address since he needs to sign the message with
   the corresponding private key, which is supposed to be known only by
   the real owner.




Haddad, et al.          Expires November 4, 2005                [Page 5]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


   CGA assures that the interface identifier part of the address is
   correct, but does little to ensure that the node is actually
   reachable at that identifier and prefix.  As a result, CGA needs to
   be employed together with a reachability test where redirection
   denial-of-service attacks are a concern.

   Each CGA is associated with a public key and auxiliary parameters.
   For OMIPv6, the public key MUST be formatted as a DER-encoded [7]
   ASN.1 structure of the type SubjectPublicKeyInfo defined in the
   Internet X.509 certificate profile [4].

   The CGA verification takes as input an IPv6 address and auxiliary
   parameters.  These parameters are the following:

   o  a 128-bit modifier, which can be any value,

   o  a 64-bit subnet prefix, which is equal to the subnet prefix of the
      CGA,

   o  an 8-bit collision count, which can have values 0, 1 and 2.

   If the verification succeeds, the verifier knows that the public key
   in the CGA parameters is the authentic public key of the address
   owner.  In order to sign a message, a node needs the CGA, the
   associated CGA parameters, the message and the private cryptographic
   key that corresponds to the public key in the CGA parameters.  The
   node needs to use a 128 bit type tag for the message from the CGA
   Message Type name space.  The type tag is an IANA-allocated 128 bit
   integer.

   To sign a message, a node performs the following two steps:

   1.  Concatenate the 128 bit type tag (in the network byte order) and
       message with the type tag to the left and message to the right.
       The concatenation is the message to be signed in the next step.

   2.  Generate the RSA signature.  The inputs to the generation
       procedure are the private key and the concatenation created in
       a).


4.  Protocol

   This section discusses first the requirements of the protocol and its
   design rationale.  An overview of the signaling is given after this,
   followed by the rules regarding the cryptographic calculations and a
   discussion of behaviour during simultaneous movements of two mobile
   nodes.



Haddad, et al.          Expires November 4, 2005                [Page 6]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


4.1  Requirements

   The main functional requirement is that the mobile node is able to
   update the correspondent node with its current location.  The
   protocol also needs to work when two mobile nodes communicate with
   each other.  Finally, the solution must be suitable with the rest of
   the Mobile IPv6 protocol [6], including, for instance, rules on how
   Mobility Header messages are processed.

   The desired characteristics of the protocol involve as small latency
   as possible upon movements, and the avoidance of signaling for non-
   moving hosts.  Other things being equal, a protocol which uses the
   smallest amount of bandwidth for signaling should be chosen.

   The security requirements for the protocol are discussed in more
   depth below:

   o  Attackers should not be able to redirect communication flows of
      legitimate hosts to themselves, at least not beyond what is
      already possible in plain IPv6.  This requirement applies both to
      ongoing and future communication flows.

   o  Attackers should not be able to redirect communication flows to
      third parties.  Otherwise, denial-of-service vulnerabilities
      exist; while such vulnerabilities already exist in the current
      Internet, we would like to avoid amplification possibilities
      introduced through mobility mechanisms.

      Note that this requirement applies even to attackers who are
      themselves parties in a legitimate communication with another
      node.

   o  Attackers should not be able to cause denial-of-service through
      the potentially expensive computations involved in the route
      optimization protocol itself.


4.2  Design Rationale

   The design of the protocol follows the same principles as in the
   original return routability protocol, but adds the following
   mechanisms in order to make it more efficient:

   CGA

      CGA provides more assurance about the correctness of claimed
      address than the pure use of routing paths.  This makes it
      possible to have a significant decrease in the signaling



Haddad, et al.          Expires November 4, 2005                [Page 7]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


      frequency.

      In addition, the public keys used in the CGA technique allow
      certain data to be communicated privately between the nodes, which
      makes some of our other techniques possible.

      This technique is taken from [17] and [11], and appeared
      originally in [9] and in [8].

   Semi-permanent security associations

      CGA alone is not very efficient, due to its reliance public key
      computations and its need for relatively long messages.  We employ
      semi-permanent security associations, created with the help of the
      CGA public keys.  After an initial CGA exchange, this makes
      subsequent signaling efficient.

      This technique appeared originally in [14].

   Minimal address testing

      CGA is unable to guarantee that a particular address is actually
      reachable at a given prefix.  For this reason there is a need for
      both home and care-of address tests.  However, due to the higher
      security of the CGA technique we can make these test much less
      frequent.

      The home address test is necessary, because otherwise a malicious
      mobile node could create a CGA for the victim network prefix,
      request a stream of packets to its current location from a public
      server, and then let the binding expire.  The result would be a
      flooding attack against the victim network.  In order to avoid
      this, we require an initial home address test at the same time as
      the CGA technique is applied.  Signaling on subsequent movements
      does not need to repeat this test, however.

      This technique appeared originally in [14].

      The care-of address test is necessary, because otherwise flooding
      attacks could be launched against unsuspecting third parties.
      This test is still performed in our protocol, though in a slightly
      different form than in RFC 3775.

      This technique appeared originally in [13].







Haddad, et al.          Expires November 4, 2005                [Page 8]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


   Home routing while moving

      Given that the per-movement signaling takes some time, mobile
      nodes can optionally request their traffic to be routed through
      their home address while this signaling is being completed.

      This technique appeared originally in [18].

   Extended Sequence Numbers

      In Secure Neighbor Discovery (SEND), CGA has been applied using
      time stamps.  However, this requires that the mobile nodes have
      somewhat accurate clocks.  In our application the concept of
      sequence numbers is more appropriate, although the base Mobile
      IPv6 sequence numbers have to be extended.  Upon initial contact
      the mobile node may send its current sequence number value to the
      correspondent node, and the mobile is expected to increase this
      value on every new signaling message to avoid replay attacks.


4.3  Overview of Signaling

   The protocol is divided into two separate cases: establishing the
   initial contact, and subsequent messaging.  The subsequent messaging
   is much more efficient than the initial contact.

   The initial phase can be rerun at any time, if either node loses its
   state, but it should be rerun at least once every 24 hours.

   The following figure shows the signaling diagram for the initial
   contact.  The options shown MUST be included in the messages, where
   conformance to this document is claimed.

   1.  MN to CN   (via HA): Pre Binding Update
   2a. CN to MN   (via HA): Pre Binding Acknowledgement
   2b. CN to MN (directly): Pre Binding Test
   3.  MN to CN (directly): Binding Update + ESN + CGA Key + SIG + BAD
   4.  CN to MN (directly): Binding Acknowledgment + ESN + SKey + BAD

   Steps 1, 2a, and 2b implement an exchange which is needed to ensure
   that the home and care-of addresses are reachable.  It is also needed
   in order to guard against CPU consumption attacks against CGA RSA
   computations.  The correspondent node SHOULD reject any Pre Binding
   Update message carrying a home address not included in its IPv6
   Destination Cache entry [3].  This ensures that at least some
   communication has taken place before the exchange (see Section 6 for
   a discussion of the security impacts of this).  Steps 2a and 2b
   provide keygen tokens which are used to construct a Kbm according to



Haddad, et al.          Expires November 4, 2005                [Page 9]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


   the usual RFC 3775 rules.

   If the correspondent node does not support a Pre Binding Update, it
   returns a regular Binding Error.  Upon receiving a Binding Error, the
   mobile node decides to fall back to the use of the standard return
   routability method or bidirectional tunneling, depending on its
   policy.

   Step 3 is the usual Binding Update, but includes the mobile node's
   public key, signature, and its extended sequence number.  At the same
   time, these three options tell the correspondent node that the mobile
   node supports this optimization.  The Binding Authorization Data
   option is included as well, and protects against replay attacks..

   In Step 4, the correspondent node it returns the deliver the semi-
   permanent security association key in the SKey option, encrypted with
   the mobile node's public key.  It also returns the Extended Sequence
   Number option.

   As a result of the initial procedure, the following state has been
   established in both nodes:

   o  A standard Binding Cache Entry.  The lifetime of the binding is
      not as severely limited as it is in standard Mobile IPv6.  The
      maximum allowed lifetime is 24 hours.

   o  The current extended sequence number value of the mobile node
      node.

   o  A semi-permanent security association with a key, Kbmperm.

   o  The public keys and other parameters (see [11]) associated with
      the addresses.

   Security-wise, we know that the parties own their addresses (via
   CGA), and we have some assurance that they are at least now at the
   locations they claim to be (via address tests).  The two endpoints
   MUST silently discard any Binding Update or Acknowledgement message
   sent and/or received, to/from any of them and not signed with the
   Kbmperm and with correct Extended Sequence Number and Mobile IPv6
   sequence number values.  The only exception to this rule applies for
   the valid Binding Update messages sent by the mobile node, containing
   the CGA Key option.

   The following figure shows the signaling diagram for subsequent
   movements.  The options shown in brackets MAY be included and other
   options MUST be included in the messages.




Haddad, et al.          Expires November 4, 2005               [Page 10]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


   1. MN to CN (directly): Care-of Test Init [+ ESN + KeepFlow + BAD]
   2. CN to MN (directly): Care-of Test
   3. MN to CN (directly): Binding Update + NI + ESN + BAD
   4. CN to MN (directly): Binding Acknowledgment + ESN + BAD

   Steps 1 through 2 implement the care-of address test operation; home
   address tests are not needed.  Note that even the care of address
   test operation might be optimized away, if some additional mechanisms
   such as [13] or [19] are employed.  Such mechanisms are outside the
   scope of this document, however.

   However, Step 1 has also another purpose.  Its goal is to inform the
   correspondent node that it is in the process of moving but has not
   yet completed the required signaling.  If the mobile node has already
   lost its previous care-of address, it includes the Extended Sequence
   Number, KeepFlow, and Binding Authorization Data options to tell the
   correspondent node that its current traffic should be redirected to
   its home address until the Binding Update arrives.  This request is
   secured through authenticating it with Kbmperm.

   Step 3 and 4 are the Binding Update and Acknowledgement.  Instead of
   the normal Kbm calculation, they are authenticated via Kbmperm'
   defined as HMAC_SHA1(care-of keygen token | Kbmperm).  Note that the
   correspondent node will send the Binding Acknowledgment message ONLY
   after a successful verification of the address owner's public key and
   the signature in the Binding Update message.  The correspondent node
   MUST use the extended sequence number sent in the Binding Update
   message to prevent against replay attacks that use past Binding
   Update messages.

   Security-wise, at this point we know that we are still talking
   between the same nodes as we did in the initial contact.  We have
   also verified the care-of address, which assures that there's no
   flooding attack going on.

4.4  Cryptographic Calculations

   The Signature option is calculated with the mobile node's private key
   over the following sequence of octets:

      Mobility Data = care-of address | correspondent | MH Data

   Where | denotes concatenation and "correspondent" is the
   correspondent node's IPv6 address.  Note that in case the
   correspondent node is mobile, correspondent refers to the
   correspondent node's home address.

   MH Data is the content of the mobility message including the MH



Haddad, et al.          Expires November 4, 2005               [Page 11]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


   header.  The Authenticator within the Binding Authorization Data
   option is zeroed for purposes of calculating the signature.

   The RSA signature is generated by using the RSASSA-PKCS1-v1_5 [5]
   signature algorithm with the SHA-1 hash algorithm.

   When the SKey option is used, the correspondent node MUST encrypt the
   Kbm with the MN's public key using the RSAES-PKCS1-v1_5 format [5].

4.5  Simultaneous Movements

   As specified in RFC 3775 [6], Mobility Header messages are generally
   sent via the mobile node's home agent and to the peer's home address,
   if it is also mobile.  This makes it possible for two mobile nodes to
   communicate even if they are moving simultaneously.  (The exceptions
   to tunneling via the home agent are the Binding Update/
   Acknowledgement messages.  In addition, Care-of Test and Init message
   are also sent directly to the current address.)

   This approach is also used in this document to ensure that
   simultaneous movements can be achieved.  That is, the Pre Binding
   Update message MUST be sent via the home agent and addressed to the
   peer's home address, if it is mobile.  The Pre Binding Acknowledgment
   message MUST be sent via the correspondent node's home agent (if any)
   and addressed to the source address of the Pre Binding Update
   message.  The Pre Binding Test message MUST be sent via the
   correspondent node's home agent (again if any), but addressed to the
   claimed care-of address from the Pre Binding Update message.

   The Binding Update, Binding Acknowledgement, Care-of Test, and
   Care-of Test Init messages follow the rules from RFC 3775.

5.  Message Formats

5.1  The Pre Binding Update Message

   This message is similar to a Binding Update message, but does not yet
   establish any state at the correspondent node.  The purpose of this
   operation is to initiate the sending of two address tests.

   This message uses MH Type <To Be Assigned By IANA>.  The format of
   the message is the following:









Haddad, et al.          Expires November 4, 2005               [Page 12]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                        Care-of Address                        +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                   Pre Binding Update Cookie                   +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Mobility Options                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved

      16-bit field reserved for future use.  This value MUST be
      initialized to zero by the sender, and MUST be ignored by the
      receiver.

   Care-of Address

      The current care-of address of the mobile node.

   Pre Binding Update Cookie

      64-bit field which contains a random value, a cookie used to
      ensure that the responses match to requests.

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  The receiver
      MUST ignore and skip any options which it does not understand.
      This specification does not define any options valid for this
      message.




Haddad, et al.          Expires November 4, 2005               [Page 13]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


   If no actual options are present in this message, no padding is
   necessary and the Header Len field will be set to 3.

   This message is tunneled through the home agent when the mobile node
   is away from home.  Such tunneling SHOULD employ IPsec ESP in tunnel
   mode between the home agent and the mobile node.  This protection is
   indicated by the IPsec security policy database, similarly to the
   protection provided for Home Test Init messages.

5.2  The Pre Binding Acknowledgement Message

   This message acknowledges a Pre Binding Update message.  The purpose
   of this acknowledgement is to provide a part of the key Kbm required
   in the initial phase of our mechanism.

   This message uses MH Type <To Be Assigned By IANA>.  The format of
   the message is the following:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                   Pre Binding Update Cookie                   +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                       Home Keygen Token                       +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Mobility Options                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved

      16-bit field reserved for future use.  This value MUST be
      initialized to zero by the sender, and MUST be ignored by the
      receiver.

   Pre Binding Update Cookie

      This 64-bit field contains the value from the same field in the
      Pre Binding Update message.



Haddad, et al.          Expires November 4, 2005               [Page 14]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


   Home Keygen Token

      This 64-bit field contains a Home Keygen Token, calculated as
      specified in RFC 3775.

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  The receiver
      MUST ignore and skip any options which it does not understand.
      This specification does not define any options valid for this
      message.

   If no actual options are present in this message, no padding is
   necessary and the Header Len field will be set to 2.

   This message is tunneled through the home agent when the mobile node
   is away from home.  Such tunneling SHOULD employ IPsec ESP in tunnel
   mode between the home agent and the mobile node.  This protection is
   indicated by the IPsec security policy database, similarly to the
   protection provided for Home Test messages.

5.3  The Pre Binding Test Message

   This message also acknowledges a Pre Binding Update message, and
   ensures that the mobile node is reachable at its claimed address.
   The purpose of this acknowledgement is to provide the second part of
   the key Kbm required in the initial phase of our mechanism.

   This message uses MH Type <To Be Assigned By IANA>.  The format of
   the message is the following:



















Haddad, et al.          Expires November 4, 2005               [Page 15]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                   Pre Binding Update Cookie                   +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                      Care-of Keygen Token                     +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Mobility Options                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved

      16-bit field reserved for future use.  This value MUST be
      initialized to zero by the sender, and MUST be ignored by the
      receiver.

   Pre Binding Update Cookie

      This 64-bit field contains the value from the same field in the
      Pre Binding Update message.

   Care-of Keygen Token

      This 64-bit field contains a Care-of Keygen Token, calculated as
      specified in RFC 3775.

   Mobility Options

      Variable-length field of such length that the complete Mobility
      Header is an integer multiple of 8 octets long.  This field
      contains zero or more TLV-encoded mobility options.  The receiver
      MUST ignore and skip any options which it does not understand.
      This specification does not define any options valid for this
      message.

   If no actual options are present in this message, no padding is
   necessary and the Header Len field will be set to 2.




Haddad, et al.          Expires November 4, 2005               [Page 16]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


5.4  The CGA Key Option

   This option is used to carry the mobile node's CGA public key and
   other parameters.  It SHOULD be inserted in any Binding Update
   message sent by the mobile node and signed with its CGA corresponding
   private key.  This option contains also all CGA parameters needed by
   the correspondent node to check the validity of the mobile node's
   CGA.

   The format of the option is the following:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |  Option Type  | Option Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     .                          CGA Parameters                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type

      <To Be Assigned By IANA>.

   Option Length

      Length of the option.

   Option Data

      This field contains the mobile node's CGA public key and other
      parameters, in the format defined in [11].


5.5  The Shared Key Option

   As it has been mentioned above, the correspondent node MUST send a
   new Kbm each time it receives a Binding Update message containing the
   CGA Parameter option.  For this purpose, this proposal uses a new
   option called SKey option, which MUST be inserted in the Binding
   Acknowledgment message.

   The format of the option is as follows:





Haddad, et al.          Expires November 4, 2005               [Page 17]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |  Option Type  |  Length = 16  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +      Semi-Permanent Key for Binding Management (Kbmperm)      +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type

      <To Be Assigned By IANA>.

   Option Length

      Length of the option.

   Option Data

      This field contains the Kbmperm value.  Note that the content of
      this field MUST be encrypted with the mobile node's public key as
      defined in Section 4.4.  The length of Kbmperm value is 20 octets
      (before encryption or padding possibly involved [5]).


5.6  The Keep Flow Option

   A mobile node which is in the process of moving may use this option
   to indicate to the correspondent node that its traffic should be
   redirected via its home address.  This option MUST always be used
   together with the Extended Sequence Number and Binding Authorization
   Data options, using the Kbmperm to authenticate the message.

   The format of the option is as follows:












Haddad, et al.          Expires November 4, 2005               [Page 18]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |  Option Type  |  Length = 16  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                         Home Address                          +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type

      <To Be Assigned By IANA>.

   Option Length

      Length of the option = 16.

   Option Data

      This field contains the home address of the mobile node.  This
      address needs to be carried here, as the Care-of Test Init message
      could not otherwise be linked to this particular node.


5.7  The Extended Sequence Number Option

   The nodes MUST use the Extended Sequence Number option in all Binding
   Acknowledgment messages in the initial phase and in all Binding
   Updates and Acknowledgement messages in the subsequent phase.  In
   addition, the Extended Sequence Number and Binding Authorization Data
   options MUST be used when the Care-of Test Init and Care-of Test
   message carries the KeepFlow option.

   The option format is as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |  Option Type  | Option Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                Extended Sequence Number                       +
     |                                                               |



Haddad, et al.          Expires November 4, 2005               [Page 19]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type

      <To Be Assigned By IANA>.

   Option Length

      Length of the option = 8.

   Option Data

      A 64 bit unsigned integer, representing the extended sequence
      number value.  The mobile node MUST increase this value every time
      it sends a new message to the correspondent node.  The
      correspondent node MUST return the most recent value it has seen.


5.8  The Signature (SIG) Option

   When the mobile node signs the Binding Update message with its CGA
   private key, it MUST insert the signature in the SIG option.  Such
   scenario occurs when the mobile node sends its first Binding Update
   message to the correspondent node and if the mobile node reboots
   during an ongoing session.

   The option format is as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |  Option Type  | Option Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     .                            Signature                          .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type

      <To Be Assigned By IANA>.

   Option Length

      Length of the option.




Haddad, et al.          Expires November 4, 2005               [Page 20]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


   Option Data

      This field contains the signature of the MH message it is
      contained within.


5.9  Status Codes

   The following new Status codes are allocated:

   Lost Kbmperm State (<To Be Allocated By IANA>)

      This code is returned when the correspondent node does not have a
      Binding Cache Entry, Kbmperm, or has an invalid Binding
      Authorization Data option.  The code MUST only be used in to
      respond to Binding Updates that contain one of the mobility
      options defined in this document.


6.  Security Considerations

   This draft describes a method to exploit the CGA features in order to
   authenticate route optimization signaling.  In fact, the CGA replaces
   the authentication by providing a proof of ownership while the RR
   procedure replaces the authentication by a routing property.

   This proof of ownership ensures that only the mobile node will be
   able to change the routing of packets destined to it, modulo
   exhaustive attacks on the CGA mechanism itself.  The feasibility of
   such attacks and the defenses against them have been discussed in
   [11].

   Note that, as specified, the proof of ownership protection applies
   only to the correspondent node believing the statements made by the
   mobile node.  There is no guarantee that the answers from the
   correspondent node truly come from that correspondent node and not
   from someone who was on the path to the correspondent node during the
   initial contact phase.  This is because we do not require
   correspondent nodes to have CGAs, and as a result, they can not make
   any statements that are authenticated in the strong sense.  We chose
   not to protect against this, because this attack is something that
   already exists in plain IPv6, as is explained in the following.  Lets
   assume that the correspondent node does not care about the IP address
   of the peers contacting it and that it does not protect its payload
   packets cryptographically.  Then, a man-in-the-middle can always use
   its own address when communicating to the correspondent node, and the
   correspondent node's address when communicating to the mobile node.
   Philosophically, one can also argue that since the problem we attempt



Haddad, et al.          Expires November 4, 2005               [Page 21]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


   to solve here is routing modifications for the mobile node's address,
   it is sufficient to ensure that these modifications are protected.

   It should be mentioned that while the CGA can provide a protection
   against unauthenticated Binding Updates, it can expose the involved
   nodes to denial-of-service attacks since it is computationally
   expensive.  The draft limits the use of CGA to only the first
   registration and if/when re-keying is needed.  In addition, it is
   RECOMMENDED that nodes track the amount of resources spent to the CGA
   processing, and disable the processing of new requests when these
   resources exceed a predefined limit.

   The method specified in this document is secure against replay and
   flooding attacks, due to the introduction of the Extended Sequence
   Number option, the use of care-of address tests, and the use of an
   initial home address test.

   The Pre Binding Update message handling deserves also some
   discussion.  In contrast to existing messages in Mobile IPv6, the
   responses to this message will be sent to two different addresses.
   As such, it may be used in amplification and redirect attacks.  In
   the following we discuss these attacks and argue that the
   vulnerability does not exceed the vulnerabilities already present in
   the current IPv6 as it is.  While the Destination Cache check is a
   very weak test, it helps in this situation because the attacker must
   have sent at least one packet beforehand.  Thus, the potential 1:2
   amplification attack is reduced to only a 2:3 amplification.  In
   addition, given that no serious attempt exists today to provide
   tracing for spoofed packets, it does not matter whether flooding
   attacks are direct, reflected from some node via a spoofed source
   address, or reflected via the Pre Binding Update message.

7.  Performance Considerations

   Performance of our protocol depends on whether we look at the initial
   or subsequent runs.  The number of messages in the initial run is one
   less as in base Mobile IPv6, but the size of the messages is
   increased somewhat.

   On a mobile node that does not move that often, there is a
   significant signaling reduction, as the lifetimes can be set higher
   than in return routability.  For instance, a mobile node that stays
   in the same address for a day will get a 99.52% signaling reduction.
   Such long lifetimes can be achieved immediately, as opposed to
   methods like [12] that grow them gradually.

   On a mobile node that moves fast, the per-movement signaling is
   reduced by 33%.



Haddad, et al.          Expires November 4, 2005               [Page 22]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


   Latency on the initial run is not affected, but on the subsequent
   movements there's a significant impact.  This is because the home
   address test is eliminated.  The exact effect depends on network
   topology, but if the home agent is far away and the correspondent
   node is on the same link, latency is almost completely eliminated.

   Additional latency and signaling improvements could be achieved
   through mechanisms that optimize the care-of address tests in some
   way.  This is outside the scope of this document, however.

8.  IANA Considerations

   This document defines a new CGA Message Type name space for use as
   type tags in messages that may be signed using CGA signatures.  The
   values in this name space are 128-bit unsigned integers.  Values in
   this name space are allocated on a First Come First Served basis [2].
   IANA assigns new 128-bit values directly without a review.

   CGA Message Type values for private use MAY be generated with a
   strong random-number generator without IANA allocation.

   This document defines a new 128-bit value under the CGA Message Type
   [11] namespace, 0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13.

   This document defines a set of new mobility options, which must be
   assigned Option Type values within the mobility option numbering
   space of [6].  This document also allocates a new Status code value.

9.  References

9.1  Normative References

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

   [2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

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

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

   [5]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
        (PKCS) #1: RSA Cryptography Specifications Version 2.1",
        RFC 3447, February 2003.



Haddad, et al.          Expires November 4, 2005               [Page 23]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


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

   [7]  International Telecommunications Union, "Information Technology
        - ASN.1 encoding rules: Specification of Basic Encoding Rules
        (BER), Canonical Encoding Rules (CER) and Distinguished Encoding
        Rules (DER)", ITU-T Recommendation X.690, July 2002.

9.2  Informative References

   [8]   O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6",
         Computer Communications Review, April 2001.

   [9]   Nikander, P., "Denial-of-Service, Address Ownership, and Early
         Authentication in the IPv6 World", Proceedings of the Cambridge
         Security Protocols Workshop, April 2001.

   [10]  Nikander, P., "Mobile IP version 6 Route Optimization Security
         Design Background", draft-ietf-mip6-ro-sec-00 (work in
         progress), April 2004.

   [11]  Aura, T., "Cryptographically Generated Addresses (CGA)",
         draft-ietf-send-cga-04 (work in progress), December 2003.

   [12]  Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding
         Lifetime Extension",
         draft-arkko-mipv6-binding-lifetime-extension-00 (work in
         progress), May 2004.

   [13]  Dupont, F. and J. Combes, "Using IPsec between Mobile and
         Correspondent IPv6 Nodes", draft-dupont-mipv6-cn-ipsec-00 (work
         in progress), April 2004.

   [14]  Haddad, W. and S. Krishnan, "Optimizing Mobile IPv6 (OMIPv6)",
         draft-haddad-mipv6-omipv6-01 (work in progress), February 2004.

   [15]  Haddad, W., "Applying Cryptographically Generated Addresses to
         BUB (BUB+)", draft-haddad-mip6-cga-bub-00 (work in progress),
         May 2004.

   [16]  Haddad, W., "BUB: Binding Update Backhauling",
         draft-haddad-mipv6-bub-01 (work in progress), February 2004.

   [17]  Roe, M., "Authentication of Mobile IPv6 Binding Updates and
         Acknowledgments", draft-roe-mobileip-updateauth-02 (work in
         progress), March 2002.

   [18]  Vogt, C., Bless, R., Doll, M., and T. Kuefner, "Early Binding



Haddad, et al.          Expires November 4, 2005               [Page 24]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


         Updates for Mobile IPv6",
         draft-vogt-mip6-early-binding-updates-00 (work in progress),
         February 2004.

   [19]  Vogt, C., Arkko, J., Bless, R., Doll, M., and T. Kuefner,
         "Credit-Based Authorization for Mobile IPv6 Early Binding
         Updates", draft-vogt-mipv6-credit-based-authorization-00 (work
         in progress), May 2004.

   [20]  Perkins, C., "Preconfigured Binding Management Keys for Mobile
         IPv6", draft-ietf-mip6-precfgKbm-00 (work in progress),
         April 2004.


Authors' Addresses

   Wassim Haddad
   Ericsson Research
   8400, Decarie Blvd
   Town of Mount Royal
   Quebec H4P 2N2, Canada

   Email: wassim.haddad@ericsson.com


   Lila Madour
   Ericsson Research
   8400, Decarie Blvd
   Town of Mount Royal
   Quebec H4P 2N2, Canada

   Email: lila.madour@ericsson.com


   Jari Arkko
   Ericsson Research
   FI-02420 Jorvas
   Finland

   Email: jari.arkko@ericsson.com











Haddad, et al.          Expires November 4, 2005               [Page 25]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


   Francis Dupont
   GET/ENST Bretagne
   Campus de Rennes 2, rue de la Chataigneraie
   CS 17607
   35576 Cesson-Sevigne Cedex
   France

   Email: Francis.Dupont@enst-bretagne.fr

Appendix A.  Acknowledgments

   The authors would like to thank Pekka Nikander, Tuomas Aura, Greg
   O'Shea, Mike Roe, Gabriel Montenegro, and Vesa Torvinen for
   interesting discussions around CGA.  The authors would also like to
   acknowledge that [17] pioneered the work in the use of CGA for Mobile
   IPv6.  Finally, we would like to thank Marcelo Bagnulo, Suresh
   Krishnan and Mohan Parthasarathy for their review and comments on
   this document.

































Haddad, et al.          Expires November 4, 2005               [Page 26]

Internet-Draft         CGA-Base MIPv6 Optimization              May 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.

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


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.





Haddad, et al.          Expires November 4, 2005               [Page 27]

Internet-Draft         CGA-Base MIPv6 Optimization              May 2005


Acknowledgment

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















































Haddad, et al.          Expires November 4, 2005               [Page 28]


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