Network Working Group                                        B. Sarikaya
Internet-Draft                                   Huawei Technologies USA
Expires: May 17, 2008                                             A. Qin
                                                                A. Huang
                                                                   W. Wu
                                                     Huawei Technologies
                                                       November 14, 2007


                   PMIPv6 Route Optimization Protocol
                    draft-qin-mipshop-pmipro-01.txt

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 May 17, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).











Sarikaya, et al.          Expires May 17, 2008                  [Page 1]


Internet-Draft          PMIPv6 Route Optimization          November 2007


Abstract

   This document defines route optimization protocol for Proxy Mobile
   IPv6.  Proxy home test, concurrent proxy care-of test and handover
   procedures based on Enhanced Route Optimization for Mobile IPv6 are
   explained.  Mobile access gateway uses cryptographically generated
   home addresses so that no more home test is needed after the initial
   home test.  Handover home keygen token is used during handover in
   order to eliminate home test for the next mobile access gateway.  The
   protocol also supports IPv4 transport network operation.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  PMIPv6 RO Scenarios and  Overview  . . . . . . . . . . . . . .  5
     3.1.  PMIPv6 RO Scenario Analysis  . . . . . . . . . . . . . . .  5
     3.2.  PMIPv6 RO Overview . . . . . . . . . . . . . . . . . . . .  6
   4.  PMIPv6 Route Optimization for Type 1 Correspondent Nodes . . .  8
     4.1.  Proxy Home Test Procedure  . . . . . . . . . . . . . . . .  8
     4.2.  Concurrent Proxy Care-of Test  . . . . . . . . . . . . . .  9
     4.3.  Handover . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.4.  Complete Proxy Binding Update  . . . . . . . . . . . . . . 11
   5.  PMIPv6 Route Optimization for Type 2 Correspondent Nodes . . . 13
     5.1.  IPv4 support . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Local Mobility Anchor Considerations . . . . . . . . . . . . . 15
   7.  Mobile Access Gateway Considerations . . . . . . . . . . . . . 16
   8.  Correspondent Node Considerations  . . . . . . . . . . . . . . 16
   9.  Requirements on PMIPv6 Handover/Context Protocol . . . . . . . 17
   10. Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 17
     10.1. Proxy Home Test  . . . . . . . . . . . . . . . . . . . . . 18
     10.2. Proxy Home Test Init Message . . . . . . . . . . . . . . . 19
     10.3. Handover Home Keygen Token option  . . . . . . . . . . . . 19
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     14.2. Informative references . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 23









Sarikaya, et al.          Expires May 17, 2008                  [Page 2]


Internet-Draft          PMIPv6 Route Optimization          November 2007


1.  Introduction

   In Mobile IPv6, the mobile nodes (MN) can establish a direct route
   with the correspondent nodes (CN), i.e. can optimize the route
   through MN establishing a binding of its Home Address (HoA) with its
   current care-of address (CoA) at CN [RFC3775].  The binding is
   established using return routability signaling and then refreshed
   periodically (every 7 minutes) and when MN's IP connectivity changes.
   Return routability procedure also called Correspondent Registrations
   involves CN's verification of MN's ownership of both HoA using a home
   address test (HoT) and CoA using care-of address test (CoT) all
   together designed to counter for the unprecedented security threats
   identified in [RFC4225] like impersonation and flooding threats.

   Return routability procedure is lightweight, does not require a
   global Public-Key Infrastructure (PKI) or preshared keys between MN
   and CN.  However, it increases signaling overhead and handoff delays.
   Return routability procedure can be optimized by using preshared keys
   [RFC4449] or cryptographically generated addresses [RFC4866].

   In Proxy Mobile IPv6 (PMIPv6) scheme, the mobility is transparent to
   mobile nodes (MN) by the mobile access gateway (MAG) simulating a
   home link and acting as a proxy on Mobile IP operation, also is
   transparent to correspondent nodes (CN) by forcing all datagrams for
   a mobile node to be routed through its local mobility anchor (LMA).
   Thus, datagrams to the mobile node are often routed along paths that
   are significantly longer than optimal.  However, packets could be
   routed directly between correspondent nodes and the mobile access
   gateway instead of through local mobility anchor, such path is
   optimal.  Moreover, immunity to impersonation, denial of service, and
   redirection-based flooding is necessary for a route optimization
   protocol in PMIPv6.  This document presents a mechanism, based on
   PMIPv6 [I-D.ietf-netlmm-proxymip6] and Enhanced Route Optimization
   for Mobile IPv6 [RFC4866], to securely establish optimal route
   between MAG and correspondent nodes or between two MAGs.

   The following types of correspondent nodes are considered:
   correspondent nodes which have both Mobile IPv6 stack defined in
   RFC3775 and recognize PMIPv6 messages, correspondent nodes without
   Mobile IPv6 function which are provided mobility support by Proxy
   Mobile IPv6.  This document discusses both the first (Type 1 CNs) and
   the second (Type 2 CNs).

   Type 1 CN's MUST support Enhanced Route Optimization for Mobile IPv6
   [RFC4866] and extensions defined in this document.  PMIPv6 RO is
   transparent for Type 2 CNs.

   Some terminology is defined in Section 2.  In Section 3 scenarios are



Sarikaya, et al.          Expires May 17, 2008                  [Page 3]


Internet-Draft          PMIPv6 Route Optimization          November 2007


   defined and an overview of PMIP6 RO is given.  Section 4 presents
   PMIPv6 Route Optimization Protocol for Type 1 CNs and Section 5
   presents for Type 2 CNs.  Section 6 defines local mobility anchor,
   Section 7 defines mobile access gateway and Section 8 defines
   correspondent node behaviour.  Section 9 is on requirements this
   protocol imposes on PMIPv6 Handover and Context Transfer protocol.
   In Section 10, formats and options of messages are defined.


2.  Terminology

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

   Most of the terminology used in this document refers to PMIPv6
   [I-D.ietf-netlmm-proxymip6], Enhanced Route Optimization for Mobile
   IPv6 [RFC4866] and [I-D.ietf-netlmm-pmip6-ipv4-support].  The changed
   definitions are listed below:

   Mobile Access Gateway (MAG)
      As is defined in [I-D.ietf-netlmm-proxymip6].  In this document,
      the route optimization function is also provided by MAG.
   Proxy Binding Cache
      A cache of mobility bindings of mobile nodes, maintained by a
      mobile access gateway for use in sending or forwarding datagrams
      to MAGs serving for these mobile nodes.
   Binding Update List
      In this document, Binding Update List data structure is extended
      to keep correspondent registrations at the mobile access gateway.
      Correspondent registration could be to another MAG for Type 2 CNs.
   Cryptographically generated home addresses
      A cryptographically generated home address enables correspondent
      nodes to securely authenticate the owner of home address (HoA), by
      means of a strong, cryptographic binding between the interface
      identifier of the address and the address owner's public key.
      From the perspective of the correspondent node, the home address
      of the mobile node is owned by mobile access gateway during route
      optimization procedure.  In this document, proxy mobile IPv6 home
      addresses are cryptographically generated home addresses using the
      mobile node's public key.
   Permanent home keygen token
      Permanent home keygen token A secret permanent home keygen token,
      which is generated by a correspondent node for a mobile node, is
      exchanged between mobile access gateway and a correspondent node.
      Permanent home keygen token kept by mobile access gateway is used
      to authenticate the mobile access gateway more efficiently in
      subsequent correspondent registrations.  The permanent home keygen



Sarikaya, et al.          Expires May 17, 2008                  [Page 4]


Internet-Draft          PMIPv6 Route Optimization          November 2007


      token is renewed over complete PBU exchange and is not used to
      authenticate the early PBU message while the mobile node moves to
      the next mobile access gateway.  Since the lifetime of proxy
      binding update is due, permanent home keygen token should be re-
      generated too.
   Handover home keygen token
      A secret handover home keygen token is a 64-bit random number
      generated by a correspondent node for a mobile node when the first
      proxy binding update containing Signature Option is received.
      Handover home keygen token is used to authenticate the early proxy
      binding update message and because of this, proxy home test after
      each handover can be skipped.  During handover, handover home
      keygen token is transferred from the previous mobile access
      gateway to the next mobile access gateway.
   Type 1 Correspondent Node
      A node that is Mobile IPv6 enabled to be a correspondent node as
      per [RFC3775].  Type 1 CNs can receive route optimized traffic
      from mobile access gateways serving their mobile nodes.
   Type 2 Correpondent Node
      A mobile node that is served by mobile access gateway.  Route
      optimization is transparent to Type 2 CNs.  Mobile access gateway
      provides both mobility and route optimization services to Type 2
      CNs.


3.  PMIPv6 RO Scenarios and  Overview

3.1.  PMIPv6 RO Scenario Analysis

   There are many possible scenarios due to the different location and
   capability of correspondent node (see Figure 1):
      o Case #1 : MN and CN attach to the same MAG and they belong to
      the same LMA.
      o Case #2 : MN and CN attach to the same MAG but they belong to
      different LMAs.
      o Case #3 : MN and CN attach to different MAGs, but they have the
      same LMA.
      o Case #4 : MN and CN attach to different MAGs, and they have
      different LMAs.
      o Case #5 : A MN is in the PMIPv6 domain and initiates route
      optimization procedures with a CN that is outside of the PMIPv6
      domain, e.g.  CN1 in Figure 1.  In this case, the CN MUST support
      route optimization procedures defined in this document.
   In Cases #1 through #4, the CN is a Type 2 CN.  The MAG of the CN is
   involved with route optimization protocol.  In Scenario #5, the CN is
   a Type 1 CN.  The MAG of the MN has to negotiate with the CN
   directly.  The route optimization mechanism should concern about the
   CN's security requirement.



Sarikaya, et al.          Expires May 17, 2008                  [Page 5]


Internet-Draft          PMIPv6 Route Optimization          November 2007


   Cases 1 and 2 do not require any signaling between PMAs and packets
   can be locally routed.  As such, these cases are covered in the base
   specification [I-D.ietf-netlmm-proxymip6].

   The protocol defined in Section 5 covers Cases #3 and #4.  PMIPv6 RO
   Protocol for Scenario Case #5 is defined in Section 4.  For Cases #3
   and #4, IPv4 transport network is supported.

                                                   /            \
                       |-----------------------|- |  Internet   |
                       |                       |   \           /
                    +-----+                 +-----+        \
                    |LMA1 |~~~~~~~~~~~~~~~~~|LMA2 |         |
                   /+-----+\\               +-----+\\    +-------+
                  //        \\                      \\   +  CN1  |
                 //          \\                      \\  +-------+
                //            \\                      \\   IPv6/IPv4
               //              \\                      \\  Transport
              //                \\                      \\ Network
         +----+                  +----+               +----+
         |MAG2|~~~~~~~~~~~~~~~~~~|MAG1|~~~~~~~~~~~~~~~|MAG3|
         +--+-+                  +-+--+               +-+--+
            |                      |                    | IPv6/IPv4
            |                      |                    | Access Network
       -----+----              ----+-------          ---+--+--
                                                           |
                   +-----+                              +--+--+
             <-----| MN1 |                              | CN2 |
                   +-----+                              +-----+

             Figure 1: Route Optimization Scenarios in PMIPv6

3.2.  PMIPv6 RO Overview

   This document describes a route optimization protocol for PMIPv6.
   For Scenarios case #3 and case #4, specialized signaling can be
   defined between mobility access gateways or between local mobility
   anchors and mobility access gateways to setup and maintain route
   optimization states for MN and CN.  However such an approach does not
   exploit the existing route optimization protocol defined for Mobile
   IPv6 in [RFC3775].  For Scenarios case #3, #4 and #5, return
   routability test procedures of Mobile IPv6 can be adopted to PMIPv6
   route optimization.  However such an approach does not leverage the
   enhancements to the return routability test procedures defined for
   Mobile IPv6 in [RFC4866].  Therefore, the protocol defined in this
   document for PMIPv6 route optimization is based on Enhanced Route
   Optimization for Mobile IPv6.




Sarikaya, et al.          Expires May 17, 2008                  [Page 6]


Internet-Draft          PMIPv6 Route Optimization          November 2007


   Once a mobile node enters its Proxy Mobile IPv6 domain, mobile access
   gateway which runs on the access router does the mobility related
   signaling on behalf of the mobile node.  In MIPv6, a mobile node may
   determine when and which correspondent node needs route optimization.
   In contrast, in this document, such determination is done by the
   mobile access gateway according to some policies.  The configuration
   of such policies is out of scope.

   As soon as mobile access gateway makes decision on which
   correspondent node needs route optimization, mobile access gateway
   initiates proxy home test procedure depicted in Section 4.1.
   Correspondent nodes verify the reachability of home address via this
   procedure.

   Correspondent nodes also need to verify the reachability of care-of
   address.  Proxy care-of test init message is piggybacked on a proxy
   binding update message which is sent by mobile access gateway on
   behalf of the mobile node to register with a correspondent node.
   After the first round trip of proxy binding update exchange is over
   between a correspondent node with mobile access gateway, the
   correspondent node sets up a binding cache entry and MAY start
   routing packets directly to care-of address of the mobile node even
   though the care-of address is not verified.  However, the mobile
   access gateway obtains care-of keygen token via this round trip of
   proxy binding update exchange [RFC4866].

   The mobile access gateway MAY initiate another proxy binding update
   exchange.  Thus, the correspondent node MAY authenticate this proxy
   binding update with both temporary home keygen token and care-of
   keygen token, and then it makes sure of the validity of proxy binding
   cache entry created by early proxy binding update exchange.  In order
   to protect against redirection-based flooding attacks, Credit-Based
   Authorization (CBA) can be exploited as described in [RFC4866].

   During handover, the next mobile access gateway simulates home link
   for the mobile node.  For the sake of security, proxy home test
   should be executed over again for correspondent node to verify the
   reachability and validity of home address of MN.  In order to reduce
   handover latency brought up with the proxy home test, handover home
   keygen token is introduced in Section 4.3.  Handover home keygen
   token is used to eliminate the home test (PHoTI-PHoT exchange) at the
   next mobile access gateway because the correspondent node can
   authenticate early proxy binding update message sent by the new MAG
   using the shared handover home keygen token.

   In PMIPv6 route optimization protocol, the proxy home test and proxy
   care-of test exchanges are initiated by MAG instead of MN.  However,
   both the source address of proxy home test init message and the



Sarikaya, et al.          Expires May 17, 2008                  [Page 7]


Internet-Draft          PMIPv6 Route Optimization          November 2007


   destination address of proxy home test message are home address of
   mobile node.  So, the destination mobile access gateway MUST
   identify, intercept and process the proxy home test init message and
   the source mobile access gateway MUST identify, intercept and process
   the proxy home test message.

   For the sake of security, cryptographically generated home addresses
   and permanent home keygen token, defined in [RFC4866], are used in
   PMIPv6 route optimization (PMIPv6RO) protocol.  Cryptographically
   generated home addresses, CGA parameters and signature are calculated
   with the mobile node's public key and private key by each MAG the
   mobile node visits.  The input parameters to the CGA calculations
   [RFC3972] like the subnet prefix, public key and private key are
   available to each MAG.  One possible mechanism is context transfer
   from the previous MAG.


4.  PMIPv6 Route Optimization for Type 1 Correspondent Nodes

4.1.  Proxy Home Test Procedure

   Proxy Home Test procedure validates the home address.  It includes
   two messages as follows:

   Proxy Home Test Init (Proxy HoTI)

   Proxy Home Test (Proxy HoT).

   Since the destination address of Proxy HoT message is the home
   address of MN, the destination MAG MUST intercept and process Proxy
   Home Test message instead of forwarding it to MN.

   When handoff occurs, correspondent nodes must re-verify the
   reachability of home address by initiating the proxy home test.  The
   next mobile access gateway MAY also initiate the proxy home test.
   Mobile access gateway MUST keep correspondent nodes list in its
   Binding Update List.  When MN roams into the next MAG, the entries in
   the Binding Update List on MN identity like NAI, private and public
   keys, etc.  SHOULD be transferred to the next MAG.

   As shown in Figure 2, the mobile access gateway imitates the Mobile
   IP client of the mobile node.  The Proxy Home Test Init (PHoTI)
   message is sent from MAG to the correspondent node, and it should be
   transmitted via the shared tunnel between the local mobility anchor
   and MAG.






Sarikaya, et al.          Expires May 17, 2008                  [Page 8]


Internet-Draft          PMIPv6 Route Optimization          November 2007


           MAG                             LMA                     CN
        According to some policies
        Decide to optimize route            |                       |
           |                                |                       |
           |==Proxy Home Test Init (PHoTI)=>|---------------------->|
           |                                |                       |
           |                                |                       |
           |<====Proxy Home Test (PHoT)=====|<----------------------|
           |                                |                       |

                    Figure 2: Proxy Home Test Procedure

4.2.  Concurrent Proxy Care-of Test

   Correspondent nodes also need to prove the reachability of care-of
   address.  In this document, since the care-of test is initiated by
   mobile access gateway instead of by mobile node, we call it as proxy
   care-of test procedure.

   The early PBU is a PBU which does not carry the care-of keygen token.
   A complete PBU follows up an early PBU after receiving a PBA message
   with a Care-of Test option as shown in Figure 3.

   a) As a Type 1 CN receives an early PBU message which contains HoA
   option, Care-of Test Init option, the CGA Parameters and Signature
   options, it returns PBA message containing a care-of keygen token in
   Care-of Test option.

   b) The MAG initiates complete proxy binding update exchange by
   sending a PBU message.  CN authenticates this proxy binding update
   with both temporary home keygen token generated during proxy home
   address test procedure and care-of keygen token.  CN also validates
   the proxy binding cache entry created by early proxy binding update
   exchange and then sends a complete PBA as a reply.

   The MAG calculates CGA parameters and signature option according to
   MN's home address.  MAG sends CGA parameters and signature in a
   complete proxy binding update message to acquire permanent home
   keygen token from the correspodent node in a PBA.  MAG adds the
   permanent home keygen token to the binding update list entry for the
   correspondent node.  The approach leverages the mechanism specified
   in section 4 in [RFC4866].









Sarikaya, et al.          Expires May 17, 2008                  [Page 9]


Internet-Draft          PMIPv6 Route Optimization          November 2007


             MAG                                             CN
              |                                               |
              | -------Early Proxy Binding Update------------>|a)
              |         (HoA, Care-of Test Init option)       |
              |                                               |
              | <------Early Proxy Binding Acknowledgement----|
              |         (HoA, Care-of Test option)            |
              |                                               |
              |-------- Complete PBU ------------------------>|b)
              |         (HoA, CGA parameters,signature...)    |
              |                                               |
              |<-------------Complete PBA---------------------|
              |         (HoA, Permanent home keygen token)    |
              |                                               |

                 Figure 3: Concurrent Proxy Care-of  Test

4.3.  Handover

   When handoff occurs, proxy care-of address changes.  CN must re-
   verify the reachability of home address.  The next MAG MAY also
   initiate the proxy home test.  Handover home keygen token is used to
   authenticate early PBU originated from the next MAG, after handover
   home keygen token is transferred from the previous MAG to the next
   MAG.  Eliminating proxy home test procedure makes the protocol more
   efficient by reducing the handover latency.

   The handover procedure is depicted in Figure 4 and the steps are
   explained below.

   a) If the previous MAG forecasts the forthcoming handover of the MN
   via layer 2 indication, the previous MAG MAY transfer context which
   includes HoA, CN addresses and corresponding handover home keygen
   tokens to the next MAG proactively.  If the MN accessed to the next
   MAG before the context is transferred, the case is a reactive case.
   In reactive handover, as soon as the next MAG detects the attachment
   of the MN, the MAG requests the private key and other pertinent
   parameters from the previous MAG if the previous MAG is known.  MAG
   MAY also obtain the private key during the authentication procedure.

   b) After the MN left the previous MAG, the previous MAG deregisters
   the Binding Cache Entry with correspondent nodes.  From this point
   on, the CN does not renew the permanent home keygen token but
   reserves the handover home keygen token for further use.

   c) After the next MAG obtains handover home keygen token from the
   previous MAG, it sends out early proxy binding update piggybacked by
   care-of test init option to correspondent nodes.  At this moment, the



Sarikaya, et al.          Expires May 17, 2008                 [Page 10]


Internet-Draft          PMIPv6 Route Optimization          November 2007


   MAG calculates the Binding Authorization Data option field of early
   proxy binding update message with handover home keygen token and
   care-of keygen token which is set to ZERO.

   d) The next MAG renews the permanent home keygen token and handover
   home keygen token via complete proxy binding update exchanges.

         Previous                     Next               Correspondent
   mobile access gateway           mobile access gateway          node

            |   Handover context     |                              |
            |----------------------->|                              |a)
            |(HoA,CN address,handover|                              |
            |home keygen token)      |                              |
   handover \\                       \\                             |
            |  Proxy binding update(lifetime = 0)                   |
            |------------------------------------------------------>|b)
            |          Proxy binding Acknowledge (if sent)          |
            |<------------------------------------------------------|
            |                        | Early Proxy Binding Update   |
            |                        |----------------------------->|c)
            |                        |  Proxy Binding Acknowledge   |
            |                        |<-----------------------------|
            |                        | Complete Proxy Binding Update|
            |                        |----------------------------->|d)
            |                        |Proxy Binding Acknowledge     |
            |                        |<-----------------------------|
            |                        |(new Permanent,               |
            |                        |Handover home keygen token)   |
            |                        |                              |

          Figure 4: Route Optimization during Handover Procedure

4.4.  Complete Proxy Binding Update

   A complete proxy binding update is a proxy binding update defined in
   [I-D.ietf-netlmm-proxymip6].  After proxy binding update which
   piggybacks care-of test exchanges is finished, a complete proxy
   binding update must be done.  The Binding Authorization Data option
   field of the complete proxy binding update is calculated by care-of
   keygen token for correspondent nodes to verify the reachability of
   care-of address and authenticate the legitimacy of the MAG which is
   sending this message on behalf of MN.  The complete proxy binding
   update is exchanged as depicted in Figure 5.

   Complete PBU message must be sent with CGA parameters and signature
   option for the mobile access gateway to request permanent home keygen
   token and handover home keygen token from the correspondent node.  A



Sarikaya, et al.          Expires May 17, 2008                 [Page 11]


Internet-Draft          PMIPv6 Route Optimization          November 2007


   CGA provides a strong binding between its interface identifier and
   the CGA owner's public key.  This enables other nodes to securely
   authenticate the CGA owner.  Depending on the strong security brought
   up with cryptographically generated home addresses, lifetime of
   binding is extended to a longer period than 7 minutes [RFC3775].
   Except for the initial test, the subsequent home tests every 7
   minutes are no longer needed.

   The correspondent node MUST authenticate the complete proxy binding
   update message based on the CGA property of the mobile node's home
   address.  If the mobile access gateway has only temporary home keygen
   token, and then the mobile access gateway uses it to calculate the
   Binding Authorization Data option for the complete proxy Binding
   Update message.

   If the mobile access gateway has permanent home keygen token, the
   mobile access gateway uses it to calculate the Binding Authorization
   Data option.  The home nonce index is set to ZERO.

   If the permanent home keygen token is required, both permanent home
   keygen token and handover home keygen token are generated and
   encrypted with the mobile access gateway's public key.  Both of the
   two tokens are transferred from correspondent node to the next mobile
   access gateway via the proxy binding acknowledgement response to the
   complete proxy binding update message.  This new handover home keygen
   token will be exploited when the next handover occurs.

   The PBA MAY be protected by CGA property of correspondent nodes.

         Mobile                                    Correspondent Node
      Access Gateway
           |         Complete Proxy Binding Update        |
           |--------------------------------------------->|
           | (CGA parameters, signature, home nonce index)|
           |                                              |
           |                                              |
           |       Proxy Binding Acknowledgement          |
           |<---------------------------------------------|
           |(Permanent home keygen token,                 |
           |           Handover home keygen token)        |
           |                                              |
           |                                              |

                  Figure 5: Complete Proxy Binding Update







Sarikaya, et al.          Expires May 17, 2008                 [Page 12]


Internet-Draft          PMIPv6 Route Optimization          November 2007


5.  PMIPv6 Route Optimization for Type 2 Correspondent Nodes

   This section describes route optimization procedure for correspondent
   nodes that are served by mobile access gateways.

   If a mobile access gateway provides mobility service for
   correspondent nodes, PMIPv6 Route Optimization protocol could be used
   for such correspondent nodes, as long as the mobile access gateway
   intercepts and processes route optimization extensions by looking
   over the MH types and distinguishing Proxy Mobile IP signaling from
   data.

   The process for Scenario case #4 is shown in Figure 6.  The proxy
   home test init message is transmitted over the shared tunnel between
   mobile access gateway and local mobility anchor of mobile node.  This
   proxy home test init message is forwarded to home address of the
   correspondent node by LMA.  At the local mobility anchor of the
   correspondent node, this message is tunnelled into the shared tunnel
   between the home agent of correspondent node and the mobile access
   gateway of the correspondent node.

   The mobile access gateway of CN intercepts proxy home test init
   message and extracts MN's home address and care-of address from
   PHoTI.  MAG of CN sends a proxy home test message back to MAG of MN
   and adds care-of address of CN into PHoT message.  MAG of CN creates
   a Binding Cache entry for this MN.  PHoT is transmitted over the
   shared tunnel between MAG of CN and LMA of CN.  LMA of CN forwards
   this message to the home address of MN which tunnels it to MAG of MN.

   MAG of MN receives PHoT message, it extracts the care-of address of
   CN and adds this information to the Binding Cache entry for CN.  MAG
   of MN next starts care-of test signaling by sending an early binding
   update message directly to the care-of address of CN, i.e. to MAG of
   CN.

   Due to the address exchange using PHoTI and PHoT messages, care-of
   test signaling in Figure 6 MUST NOT be started in parallel to home
   test signaling.

   Since the mobile access gateway is sending PBA on behalf of the
   correspondent node, that mobile access gateway SHOULD use the
   correspondent node's CGA property to protect PBA.









Sarikaya, et al.          Expires May 17, 2008                 [Page 13]


Internet-Draft          PMIPv6 Route Optimization          November 2007


         MAG(MN)       LMA(MN)         LMA(CN)          MAG(CN)
         |    Proxy HoTI  |               |                |
         |===============>|-------------->|===============>|
         |    Proxy HoT   |               |                |
         |<===============|<--------------|<===============|
         |   Early Proxy Binding Update   |                |
         |------------------------------------------------>|
         |   Proxy Binding Acknowledgement|                |
         |<------------------------------------------------|
         |   Complete Proxy Binding Update|                |
         |------------------------------------------------>|
         |   Proxy Binding Acknowledgement|                |
         |<------------------------------------------------|
         |                                |                |

        Figure 6: Route Optimization for Type 2 Correspondent Nodes

   Scenario case #3 route optimization is a simpler case of Figure 6.
   LMA of MN has to re-encapsulate each packet and send it in MAG-LMA
   tunnel of CN's MAG and back in MAG-LMA tunnel of MN's MAG.

5.1.  IPv4 support

   The typical IPv4 transport network scenario is as follows: both the
   MN and the CN, located in PMIP domains, are IPv6-enabled nodes,
   allocated IPv6 addresses and being served by dual-stack MAGs.  The
   transport network between the LMA and the MAG is an IPv4 network.

   Initially, both MN and CN configure IPv4 home addresses by exchanging
   PBU/PBA as explained in [I-D.ietf-netlmm-pmip6-ipv4-support].  In
   Scenario case #3, MAG of MN starts RO signaling by sending PHoTI
   message to CN in IPv4 tunnel established between MAG and LMA of MN.
   MAG of MN MUST add IPv4 care-of address of MN into the care-of
   address field of PHoTI.  LMA removes IPv4 header and looks at the
   destination address of inner header.  LMA finds MAG address of this
   CN and sends PHoTI in IPv4 tunnel between MAG and LMA of CN.  PHoTI
   message sent from MAG to LMA is shown at Figure 7:

   PHoTI message:
        IPv4 header (src=MAG of MN's IPv4 P.CoA, dst=IPv4 LMAA)
           IPv6 header (src=MN's IPv6 HoA, dst=IPv6 HoA of CN)
                Mobility header
                  - Proxy HoTI
                  IPv4 care-of address of MN
                Mobility Options

                          Figure 7: PHoTI message




Sarikaya, et al.          Expires May 17, 2008                 [Page 14]


Internet-Draft          PMIPv6 Route Optimization          November 2007


   MAG of CN sends a PHoT message as a reply.  PHoT message is sent in
   IPv4 tunnel to LMA encapsulated in an IPv4 header.  MAG of CN must
   add IPv4 care-of address of CN into the care-of address field of
   PHoT.  PHoT message gets routed to MN.  MAG of MN MUST obtain IPv4
   address of CN from PHoT message's care-of address field.  This
   establishes direct route between MN and CN.

   PHoT message:
         IPv4 header (src= MAG of CN's IPv4
                 P.CoA, dst= IPv4 LMAA)
           IPv6 header (src=MAG of CN's IPv6 P.CoA, dst=IPv6 HoA of MN)
             Mobility header
               - PHoT
               IPv4 care-of address of CN
             Mobility Options

                          Figure 8: PHoT message

   In Scenario case #4, after receiving PHoTI message, LMA of MN needs
   to map IPv6 home address of CN to either IPv4 address of CN's LMA or
   IPv4 home address of CN.  One possible solution is that MAG of MN
   includes IPv4 home address of CN in PHoTI message.  LMA of MN then
   sends pHoTI message in an IPv4 tunnel to CN which is received by LMA
   of CN.  LMA of CN processes PHoTI exactly like LMA of CN did in
   Scenario case #3 and sends the message to MAG of CN.

   MAG of CN sends a PHoT message as a reply.  PHoT message is sent in
   IPv4 tunnel to LMA of CN encapsulated in an IPv4 header.  MAG of CN
   must add IPv4 care-of address of CN into the care-of address field of
   PHoT.  MAG of CN must also add IPv4 address of MN into the care-of
   address field of PHoT.  PHoT message gets routed to MN.  MAG of MN
   MUST obtain IPv4 address of CN from PHoT message's care-of address
   field.  This establishes direct route between MN and CN.

   For supporting IPv4 private address space, NAT detection Option is
   required from the DSMIP6 specification
   [I-D.ietf-mip6-nemo-v4traversal].  For the NAT handling, UDP header
   MUST be always used for the proxy binding update.  These operations
   are defined in [I-D.ietf-netlmm-pmip6-ipv4-support].


6.  Local Mobility Anchor Considerations

   The local mobility anchor MUST drop all HoTI messages received from a
   home address that has corresponding Binding Cache entry with the
   proxy registration flag set.  The local mobility anchor MUST forward
   all Proxy HoTI messages received from a home address that has
   corresponding Binding Cache entry with the proxy registration flag



Sarikaya, et al.          Expires May 17, 2008                 [Page 15]


Internet-Draft          PMIPv6 Route Optimization          November 2007


   set.


7.  Mobile Access Gateway Considerations

   MAG, after successful Home and Care-of Test exchanges, creates a
   Binding Cache entry for the correspondent node or MAG of the
   correspondent node.  For each mobile node, the Binding Cache contains
   one entry for each correspondent node.  After handover, context
   transfer procedure and PBU with lifetime set to zero exchanges are
   finished, the previous MAG deletes deletes the Binding Cache entry
   and deregisters MN with all its correspondent nodes.

   MAG MUST maintain a Binding Update List for each MN.  The fields are
   as defined in [RFC3775] and with extensions defined in
   [I-D.ietf-netlmm-proxymip6].  For each MN for which route
   optimization service is offered, the list in addition MUST contain
   the private and public keys of MN as well as the permanent home
   keygen token and handover home keygen token.  Apart from home
   registrations as in [I-D.ietf-netlmm-proxymip6], Binding Update List
   contains correspondent registrations for route optimization.

   After handover, correspondent registration entries in the Binding
   Update List SHOULD be transferred to the next MAG except for the
   permanent home keygen token.  Such a transfer provides continuity of
   correspondent registrations for route optimization.  The next MAG
   refreshes such registrations only after lifetime expiry.

   MAG MUST maintain a Binding Cache if it has Type 2 CNs.  Binding
   cache entries are created when MAG receives a home test init message.
   This Binding Cache is called Proxy Binding Cache.

   From the correspondent nodes MAG receives data packets with Type 2
   routing header.  Type 2 routing header MUST conform to the structure
   given in Section 6.1.5 of [RFC3775].  MAG MUST process the packet as
   follows: MAG replaces the source address with the home address given
   in Type 2 routing header.  MAG removes Type 2 routing header.  MAG
   sends the packet to MN.


8.  Correspondent Node Considerations

   This section states the differences in the behaviour of a
   correspondent node that conforms to Section 9 of [RFC3775] and
   [RFC4866].

   Upon receiving a Proxy Home Test Init message, Early Proxy Binding
   Update and Complete Proxy Binding Update message, the correspondent



Sarikaya, et al.          Expires May 17, 2008                 [Page 16]


Internet-Draft          PMIPv6 Route Optimization          November 2007


   node verifies the following: The packet MUST NOT include a Home
   Address destination option.  The correspondent node MUST silently
   ignore such packets.

   Correspondent nodes MUST have a handover home keygen token in the
   binding cache entry for each mobile node they are involved in route
   optimized communication.

   After a successful Home and Care-of Test exchanges, the correspondent
   node creates a Binding Cache entry for the mobile access gateway
   proxying the mobile node.  The entry MUST be deleted after the
   expiration of its lifetime or after receiving a proxy binding update
   message which deregisters the mobile node.

   Correspondent node MUST receive route optimized data packets from MAG
   encapsulated in IP-in-IP encapsulation.  Source address of the outer
   header MUST be equal MAG's egress interface address and MUST match
   the Binding Cache entry.  CN MUST remove the outer header before
   passing the packet to the upper layers.

   CN MUST use Type 2 routing header in outgoing packets to MAG.  The
   destination address is MAG's egress interface address which serves as
   Care-of address for the mobile node and the type 2 routing header
   contains MN's home address.


9.  Requirements on PMIPv6 Handover/Context Protocol

   PMIPv6 RO Protocol has the following requirements on PMIPv6 Handover/
   Context Transfer protocol: Context transfer from the previous MAG to
   the next MAG SHOULD include:

   HoA of MN, Home Network Prefix (HNP) of MN,

   Address of each CN and handover home keygen token from the Binding
   Update list entry for this MN,

   Permanent home keygen token,

   Private and public key of MN.


10.  Message Formats

   This section defines extensions to the Proxy Mobile IPv6
   [I-D.ietf-netlmm-proxymip6] protocol messages and the enhanced route
   optimization in MIPv6 protocol messages [RFC4866].




Sarikaya, et al.          Expires May 17, 2008                 [Page 17]


Internet-Draft          PMIPv6 Route Optimization          November 2007


10.1.  Proxy Home Test
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |       Home Nonce Index        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                        Home Init Cookie                       +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                        Home Keygen Token                      +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                        Care-of Address                        +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility options                       .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A new MH type should be assigned by IANA.

   Home Keygen Token
      This field contains the 64 bit temporary home keygen token used to
      authenticate the proxy binding update.

   Care-of Address
      This field contains the care-of address assigned to the CN by MAG.
   For descriptions of other fields present in this message, refer to
   section 6.1.5 in [RFC3775].














Sarikaya, et al.          Expires May 17, 2008                 [Page 18]


Internet-Draft          PMIPv6 Route Optimization          November 2007


10.2.  Proxy Home Test Init Message
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |           Reserved            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                       Home Init Cookie                        +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                        Care-of Address                        +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                       Mobility Options                        .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A new MH type should be assigned by IANA.

   Care-of Address
      This field contains the care-of address assigned to the mobile
      node by MAG.
   For descriptions of other fields present in this message, refer to
   section 6.1.5 in [RFC3775].

10.3.  Handover Home Keygen Token option

   Handover home keygen token is a mobility option.  It is sent by CN in
   proxy binding acknowledgement message.

        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 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       :                                                               :
       :                  Handover Home Keygen Token                   :
       :                                                               :
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Sarikaya, et al.          Expires May 17, 2008                 [Page 19]


Internet-Draft          PMIPv6 Route Optimization          November 2007


   Option Type
      8-bit identifier of the type of this mobility option.  Its value
      is TBD by IANA.

   Option Length
      8-bit unsigned integer representing the length of the Handover
      Home Keygen Token field in octets.
   Handover Home Keygen Token
      This field contains the Handover home keygen token generated by
      the correspondent node.  The content of this field MUST be
      encrypted with the mobile access gateway's public key.  The length
      of the handover home keygen token is 8 octets before encryption.
      After it is encrypted, this field may be longer than 8 octets.


11.  IANA Considerations

   TBD.


12.  Security Considerations

   Security mechanism is very important in the route optimization
   process, especially for the proposal of establishing the tunnel
   between two mobile access gateways.  In the case of route
   optimization without return routability, if mobile access gateway
   does not authenticate Proxy Binding Update and Proxy Binding
   Acknowledge messages, a malicious node may send such signaling
   messages to mobile access gateways to get the data packets destined
   for other nodes directed to itself.

   In addition, when mobile access gateway sends data packets through
   the bi-directional tunnel between two mobile access gateways,
   corresponding MAG SHOULD examine the data packets to make sure there
   is a Binding Cache entry for the data source terminal.

   Route optimization signaling between MAG of MN and CN specified in
   this document is based on [RFC4866] and use return routability with
   better security properties than the return routability of the base
   protocol [RFC3775].

   Return routability signaling between two MAGs specified in this
   document is also based on [RFC4866] and has better security
   properties.







Sarikaya, et al.          Expires May 17, 2008                 [Page 20]


Internet-Draft          PMIPv6 Route Optimization          November 2007


13.  Acknowledgements

   We would like to thank Dr. Vogt for his comments that have lead to
   many improvements in this document.


14.  References

14.1.  Normative References

   [I-D.ietf-netlmm-pmip6-ipv4-support]
              Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-01
              (work in progress), July 2007.

   [I-D.ietf-netlmm-proxymip6]
              Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6",
              draft-ietf-netlmm-proxymip6-07 (work in progress),
              November 2007.

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

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

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.

   [RFC4866]  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
              Optimization for Mobile IPv6", RFC 4866, May 2007.

14.2.  Informative references

   [I-D.ietf-mip6-nemo-v4traversal]
              Soliman, H., "Mobile IPv6 support for dual stack Hosts and
              Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-05
              (work in progress), July 2007.

   [RFC4225]  Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
              Nordmark, "Mobile IP Version 6 Route Optimization Security
              Design Background", RFC 4225, December 2005.

   [RFC4449]  Perkins, C., "Securing Mobile IPv6 Route Optimization
              Using a Static Shared Key", RFC 4449, June 2006.





Sarikaya, et al.          Expires May 17, 2008                 [Page 21]


Internet-Draft          PMIPv6 Route Optimization          November 2007


Authors' Addresses

   Behcet Sarikaya
   Huawei Technologies USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Email: sarikaya@ieee.org


   Alice Qin
   Huawei Technologies
   No.91 BaiXia Rd.
   Nanjing, Jiangsu  210001
   China

   Email: Alice.Q@huawei.com


   Andy Huang
   Huawei Technologies
   No.91 BaiXia Rd.
   Nanjing, Jiangsu  210001
   China

   Phone: +86-25-84565457
   Email: hpanda@huawei.com


   Wenson Wu
   Huawei Technologies
   No.91 BaiXia Rd.
   Nanjing, Jiangsu  210001
   China

   Phone: +86-25-84565459
   Email: sunseawq@huawei.com














Sarikaya, et al.          Expires May 17, 2008                 [Page 22]


Internet-Draft          PMIPv6 Route Optimization          November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Sarikaya, et al.          Expires May 17, 2008                 [Page 23]