Subject: Re: [netlmm] Welcome your comments on draft-qin-mipshop-pmipro-00.txt

From: Jun Lei <[email-masked]>
Date: Tue, 17 Apr 2007 10:44:38 +0200

Dear Alice,

It seems that the key idea behind the draft is mainly based on the 
"enhanced route optimization for MIPv6" and the cryptography part is 
motivated from CGA.

Just few comments.

1. As you have mentioned, it requires more efforts to determine which CN 
needs route optimization. It seems that PMA will do this job. Any other 
methods? At least, the mechanism described here is not clear to me.

2. In the Sec3.1, you mentioned

"the PMA may initiate another PBU exchange. Thus, the CN may 
authenticate this PBU with both temporary home keygen token and Care of 
keygen token....".

I am a little confused. Where is the definition or clarification of 
temporary home keygen token and care of keygen token? And what's purpose 
of them?

3. In sec3.4, you mentioned

"As soon as the complete PBU message is received by the CN, .... This 
PBU contains CGA parameters and signature...."

To my understanding, "this PBU" should be "Early PBU". Is that right? 
The description of the figure 4 is not very explicitly clear.

4. In sec 3.5, it is mentioned

"If the permanent home keygen token is required, both permanent home 
keygen token and handover home keygen token are generated ...."

I am not quite sure about the above explanation since currently PMA 
doesn't hold the permanent home keygen token. Is that right?

5. From the very beginning, the draft claims that this protocol also 
support inter-domain case. However, it is hardly to find the explicit 
defintion of how to support it. After reading, I have a kind of feeling 
that this protocol could only support intra-domain case. Could you 
please give a scenario, which might be helpful.

Cheers

Jun

> Hello All,
>        My new draft is available, please review it,
> http://tools.ietf.org/wg/mipshop/draft-qin-mipshop-pmipro-00.txt
> 
>    This document defines route optimization protocol for Proxy Mobile     
>    IPv6.  Proxy home test, concurrent proxy care-of test and handover     
>    procedures are explained.  Proxy mobile agent 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 proxy mobile     
>    agent.  A different route optimization protocol is defined for inter-  
>    proxy mobile agent operation if the correspondent node is not Mobile   
>    IPv6 enabled.                                                          
> 
> 
> your comments are sincerely welcome.
> 
> Best regards
> 
> Alice Qin
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> Network Working Group                                             A. Qin
> Internet-Draft                                                  A. Huang
> Expires: August 29, 2007                                           W. Wu
>                                                              B. Sarikaya
>                                                      Huawei Technologies
>                                                        February 25, 2007
> 
> 
>                    PMIPv6 Route Optimization Protocol
>                     draft-qin-mipshop-pmipro-00.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 August 29, 2007.
> 
> Copyright Notice
> 
>    Copyright (C) The IETF Trust (2007).
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Qin, et al.              Expires August 29, 2007                [Page 1]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
> Abstract
> 
>    This document defines route optimization protocol for PMIPv6.  Proxy
>    home test, concurrent proxy care-of test and handover procedures are
>    explained.  Proxy mobile agent 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 proxy mobile agent.  A different
>    route optimization protocol is defined for inter-proxy mobile agent
>    operation if the correspondent node is not Mobile IPv6 enabled.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Qin, et al.              Expires August 29, 2007                [Page 2]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
> 1.  Introduction
> 
>    In Proxy Mobile IPv6 (PMIPv6) scheme, the mobility is transparent to
>    mobile nodes (MN) by the Proxy Mobility Agent (PMA) 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 home agent (HA).  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 proxy mobile agent
>    instead of through home agent, 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 [4] and Enhanced
>    Route Optimization for Mobile IPv6 [5], to securely establish optimal
>    route path between PMA and correspondent nodes or between two PMAs.
> 
>    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, as well as a fixed correspondent node without mobility.
>    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
>    [5] and extensions defined in this document.  PMIPv6 RO is
>    transparent for Type 2 CNs.
> 
>    Some terminology is defined in Section 2.  Section 3 presents PMIPv6
>    Route Optimization Protocol for Type 1 CNs and Section 4 presents
>    inter-PMA route optimization protocol for Type 2 CNs.  Section 5
>    defines home agent, Section 6 defines proxy mobile agent and
>    Section 7 defines correspondent node behaviour.  In Section 8,
>    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 [1].
> 
>    Proxy Mobile Agent (PMA)
>       The proxy mobile agent is a functional element on the access
>       router, which is defined in [4].  In PMIPv6, proxy mobile agent
>       acts an Mobile Ip client agent of MN.  In this document, the route
>       optimization function is also provided by PMA.
> 
> 
> 
> Qin, et al.              Expires August 29, 2007                [Page 3]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
>    Proxy Binding Cache
>       A cache of mobility bindings of mobile nodes, maintained by a
>       proxy mobile agent for use in sending or forwarding datagrams to
>       PMAs serving for these mobile nodes.
>    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 correspondent node, the home address of
>       the mobile node is owned by proxy mobile agent during route
>       optimization procedure.  In this document, proxy mobile IPv6 home
>       addresses are cryptographically generated home addresses using its
>       mobile node's public key.  Home prefix could be per-MN prefix or
>       shared prefix.
>    Permanent home keygen token
>       A secret permanent home keygen token, which is generated by a
>       correspondent node for a mobile node, is exchanged between proxy
>       mobile agent and a correspondent node.  Permanent home keygen
>       token is kept by proxy mobile agent.  The permanent home keygen
>       token is used to authenticate the proxy mobile agent more
>       efficiently in subsequent correspondent registrations.  The
>       permanent home keygen token is renewed as soon as the mobile node
>       moves to the next proxy mobile agent.  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 used during handover, which
>       is generated by a correspondent node for a mobile node.  Handover
>       home keygen token, kept by proxy mobile agent, is obtained along
>       with permanent home keygen token at initial time.  However, it
>       will be not out-of-date even though the registration lifetime is
>       due.  During handover, handover home keygen token is transferred
>       from the previous proxy mobile agent to the next proxy mobile
>       agent.  The next proxy mobile agent uses this token to
>       authenticate the proxy binding update.
>    Type 1 Correspondent Node
>       A node that is Mobile IPv6 enabled to be a correspondent node as
>       per [2].  Type 1 CNs can receive route optimized traffic from
>       proxy mobile agents serving their mobile nodes.
>    Type 2 Correpondent Node
>       A mobile node that is served by proxy mobile agent.  Route
>       optimization is transparent to Type 2 CNs.  Proxy mobile agent
>       provides both mobility and route optimization services to Type 2
>       CNs.
> 
> 
> 
> 
> 
> 
> Qin, et al.              Expires August 29, 2007                [Page 4]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
> 3.  PMIPv6 Route Optimization Protocol
> 
>    This section consists of a set of approaches to meet requirements of
>    route optimization for PMIPv6.
> 
> 3.1.  Route Optimization for PMIPv6 Overview
> 
>    This document describes a route optimization protocol for PMIPv6.
>    This protocol is based on PMIPv6 and Enhanced Route Optimization for
>    Mobile IPv6.
> 
>    Once a mobile node enters its Proxy Mobile IPv6 domain, proxy mobile
>    agent 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, access router MAY inform proxy mobile agent to initiate
>    route optimization procedure according to some policies in PMIPv6.
>    The configuration of such policies is out of scope.
> 
>    As soon as proxy mobile agent makes decision on which correspondent
>    node needs route optimization, proxy mobile agent initiates proxy
>    home test procedure depicted in Section 3.2.  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 proxy mobile agent 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 proxy mobile agent, 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 proxy mobile agent obtains care-of
>    keygen token via this round trip of proxy binding update exchange.
> 
>    The proxy mobile agent 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 [5].
> 
>    During handover, the next proxy mobile agent 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 rachability
>    and validity of home address of MN.  In order to reduce handover
>    latency brought up with the proxy home test, handover home keygen
> 
> 
> 
> Qin, et al.              Expires August 29, 2007                [Page 5]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
>    token is introduced in Section 3.4.
> 
>    In PMIPv6 route optimization protocol, the proxy home test and proxy
>    care-of test exchanges are initiated by PMA instead of MN.  However,
>    both the source address of proxy home test init message and the
>    destination address of proxy home test message are home address of
>    mobile node.  So, the proxy mobile agent MUST identify, intercept and
>    process the home test messages.
> 
>    For the sake of security, cryptographically generated home addresses
>    and permanent home keygen token, defined in [5], 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 PMA the mobile node
>    visits.  The input parameters to the CGA calculations [3] like the
>    subnet prefix, public key and private key are available to each PMA.
>    One possible mechanism is context transfer from the previous PMA.  In
>    order to decrease handover latency, handover home keygen token is
>    introduced in PMIPv6RO as a credential for the next proxy mobile
>    agent to be more efficient by means of eliminating home test
>    procedure.
> 
>    As shown in Figure 1, the optimal route path is depicted by slashes
>    which connect correspondent node with proxy mobile agent.
>                   +------+                   +----+
>                   |  HA  |-------------------| CN |
>                   +------+                   +----+
>                      | HAA                      |
>                      |     +--------------------+
>                    // \\  /                    /
>                   //   \\/                    /
>        +---------//-----/--------------------/--+
>        |        //     /  \\ PMIP Network   /   |
>        +-------//-----/----\\--------------/----+
>               //     /      \\            /
>              //     /        \\          /
>             //+----+          \\+-------/
>        CoA1 | |               | CoA2
>          +----+              +----+
>          |PMA1|<- policies   |PMA2|<- policies
>          +----+  for RO      +----+  for RO
>             |                   |
>                  -.-.->       [MN] HoA
> 
>                Figure 1: PMIPv6 Route Optimization Operation
> 
> 
> 
> 
> 
> 
> Qin, et al.              Expires August 29, 2007                [Page 6]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
> 3.2.  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 PMA 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.  The next proxy mobile agent MAY also
>    initiate the proxy home test.  Proxy mobile agent must keep
>    correspondent nodes list in its Binding Update List.  When MN roams
>    into the next PMA, these Binding Update List entries SHOULD be
>    transferred to the next PMA using context transfer protocol or other
>    protocols.  When MN roams into the next PMA, the entries in the
>    Binding Update List on MN identity like NAI, private and public keys,
>    etc.  SHOULD be transferred to the next PMA.  The context transfer
>    protocol is out of scope.
> 
>    As shown in Figure 2, the proxy mobile agent imitates the Mobile IP
>    client of the mobile node.  The Proxy Home Test Init (PHoTI) message
>    is sent from PMA to the correspondent node, and it should be
>    transmitted via the shared tunnel between the Home Agent and PMA.
>     Proxy Mobile Agent                 Home agent    Correspondent node
> 
>         According to some policies
>         Decide to optimize route path       |                       |
>            |                                |                       |
>            |==Proxy Home Test Init (PHoTI)=>|---------------------->|
>            |                                |                       |
>            |                                |                       |
>            |<====Proxy Home Test (PHoT)=====|<----------------------|
>            |                                |                       |
> 
>                     Figure 2: Proxy Home Test Procedure
> 
> 3.3.  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
>    proxy mobile agent instead of by mobile node, we call it as proxy
>    care-of test procedure in order to differentiate the procedure from
>    the definition in MIPv6 [2].
> 
> 
> 
> Qin, et al.              Expires August 29, 2007                [Page 7]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
>    Proxy care-of test is piggybacked on a proxy binding update which is
>    sent by proxy mobile agent on behalf of the mobile node to register
>    with a correspondent node.  The care-of test is done concurrently
>    with proxy binding update exchange, so we call it concurrent proxy
>    care-of test.  As shown in Figure 3, as a correspondent node receives
>    a proxy binding update message, which contains care-of test init
>    option, the CGA Parameters and Signature options, it returns a
>    care-of keygen token in care-of test option piggybacked onto proxy
>    binding acknowledgement (PBA) message.  The mechanism is as described
>    in [5].
> 
>    After the first round trip of proxy binding update exchange is over
>    between a correspondent node with proxy mobile agent, the
>    correspondent node sets up a binding cache entry and may route
>    packets directly to care-of address of the mobile node even though
>    the care-of address is not verified.  However, the proxy mobile agent
>    obtains care-of keygen token via this round trip of proxy binding
>    update exchange.  The proxy mobile agent 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 that
>    the proxy binding cache entry created by early proxy binding update
>    exchange is legitimate.  In order to protect against redirection-
>    based flooding attacks, Credit-Based Authorization is also exploited,
>    which is already introduced in [5].
> 
>    If proxy mobile agent has only temporary home keygen token instead of
>    permanent home keygen token, the proxy mobile agent calculates the
>    Binding Authorization Data option field of early proxy binding update
>    message with temporary home keygen token and care-of keygen token
>    which is set to ZERO.  Proxy mobile agent calculates CGA parameters
>    and signature option according to MN's home address and private and
>    public keys to be sent in a proxy binding update message to acquire
>    permanent home keygen token and handover home keygen token.
> 
>    If proxy mobile agent has permanent home keygen token, proxy mobile
>    agent calculates the Binding Authorization Data option field of early
>    proxy binding update with permanent home keygen token and care-of
>    keygen token which is set to ZERO.  No CGA parameters and signature
>    are required.
> 
>    If proxy mobile agent has only handover home keygen token, the proxy
>    mobile agent 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.  In order to renew
>    permanent home keygen token and handover home keygen token, proxy
>    mobile agent must include MN's CGA parameters and signature in this
>    early proxy binding update.
> 
> 
> 
> Qin, et al.              Expires August 29, 2007                [Page 8]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
>    Concurrent proxy care-of test procedure should proceed as soon as
>    mobile node moves into the next PMA.  To save handoff latency,
>    concurrent proxy care-of test is piggybacked onto early proxy binding
>    update exchange.  As handoff occurs, the next proxy mobile agent
>    calculates the Binding Authorization Data option for early proxy
>    binding update based on handover home keygen token if the next proxy
>    mobile agent has already obtained the handover home keygen token.
>    The next proxy mobile agent and correspondent nodes can resume
>    communication, while care-of address reachability verification
>    proceeds concurrently.  The amount of data, which the correspondent
>    node is permitted to send to care-of address until reachability
>    verification completes, is governed by Credit-Based Authorization.
>    This mechanism conforms to [5].
> 
>               Proxy                                   Correspondent
>           Mobile Agent                                     Node
>               |                                               |
>               | -------Early Proxy Binding Update------------>|
>               |         (care-of test init option)            |
>               |                                               |
>               | <------Proxy Binding Acknowledgement----------|
>               |          (care-of test option)                |
>               |                                               |
> 
>                  Figure 3: Concurrent Proxy Care-of  Test
> 
> 3.4.  Handover
> 
>    Route optimization during handover is shown as Figure 4.
> 
>    If the previous proxy mobile agent forecasts the forthcoming handover
>    of mobile node via layer 2 indication, such as link going down event
>    in the Media-Independent Handover, the previous proxy mobile agent
>    MAY transfer handover context to the next proxy mobile agent in
>    advance.  The handover home keygen token and other key parameters
>    could help the next proxy mobile agent to pass the verification of
>    home address required by correspondent nodes.  The next proxy mobile
>    agent MAY fetch the handover home keygen token through home agent via
>    proxy binding update exchanges with the home agent of mobile node.
> 
>    After the mobile node left the previous proxy mobile agent, the
>    previous proxy mobile agent deregisters the proxy binding cache entry
>    with correspondent nodes.  The correspondent node revokes permanent
>    home keygen token.  After the next proxy mobile agent obtains
>    handover home keygen token, it sends out proxy binding update
>    piggybacked by care-of test init option to correspondent nodes.
> 
>    As depicted in Figure 4, after the next proxy mobile agent obtains
> 
> 
> 
> Qin, et al.              Expires August 29, 2007                [Page 9]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
>    the care-of keygen token via early proxy binding update and
>    acknowledges messages, the binding cache entry is generated but
>    unverified in the correspondent node.  As soon as the complete proxy
>    binding update message is received by the correspondent node, the
>    binding cache entry could be verified.  This proxy binding update
>    contains CGA parameters and signature option with proxy mobile
>    agent's public key and private key to request care-of keygen token.
> 
>    The correspondent node receives the proxy binding update and
>    authenticates it with handover home keygen token and with CGA
>    property.  If the proxy binding update passes the verification, the
>    correspondent node returns a care-of keygen token which is encrypted
>    with the next proxy mobile agent's public key.  The care-of keygen
>    token is encrypted and sent over proxy binding acknowledgement
>    message as a field.  As soon as the next proxy mobile agent receives
>    this proxy binding acknowledgement, it sends a complete proxy binding
>    update message to the correspondent nodes.  Binding Authorization
>    Data option of the complete proxy binding update message is
>    calculated using both care-of keygen token and handover home keygen
>    token.
> 
>          Previous                     Next               Correspondent
>    Proxy mobile Agent           Proxy mobile agent             node
> 
>             |   Handover context     |                              |
>             |----------------------->|                              |
>             |(HoA,CN address,handover|                              |
>             |home keygen token)      |                              |
>    handover \\                       \\                             |
>             |  Proxy binding update(lifetime = 0)                   |
>             |------------------------------------------------------>|
>             |          Proxy binding Acknowledge (if sent)          |
>             |<------------------------------------------------------|
>             |                        | Early Proxy Binding Update   |
>             |                        |----------------------------->|
>             |                        |  Proxy Binding Acknowledge   |
>             |                        |<-----------------------------|
>             |                        | Complete Proxy Binding Update|
>             |                        |----------------------------->|
>             |                        |Proxy Binding Acknowledge     |
>             |                        |<-----------------------------|
>             |                        |(new Permanent,               |
>             |                        |Handover home keygen token)   |
>             |                        |                              |
> 
>           Figure 4: Route Optimization during Handover Procedure
> 
> 
> 
> 
> 
> Qin, et al.              Expires August 29, 2007               [Page 10]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
> 3.5.  Complete Proxy Binding Update
> 
>    A complete proxy binding update is a proxy binding update defined in
>    [4].  After proxy binding update which piggybacks care-of test
>    exchanges is finished, a complete proxy binding update must be
>    brought forward.  The Binding Authorization Data option field of it
>    is calculated by care-of keygen token for correspondent nodes to
>    verify the reachability of care-of address and authenticate the
>    legitimacy of the PMA which is sending this message on behalf of MN.
>    The complete proxy binding update is exchanged as depicted in
>    Figure 5.
> 
>    After proxy care-of test is processed, the complete proxy binding
>    update exchange follows Figure 5.  PBU message must be sent with CGA
>    parameters and signature option for the proxy mobile agent to request
>    permanent home keygen token and handover home keygen token from the
>    correspondent node.  A 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 more
>    than 7 minutes [2].  Except for the initial test, the following 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 proxy mobile agent has only temporary home keygen
>    token, and then the proxy mobile agent uses it to calculate the
>    Binding Authorization Data option for the complete proxy Binding
>    Update message.
> 
>    If the proxy mobile agent has permanent home keygen token, the proxy
>    mobile agent 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 proxy mobile agent's public key.  Both of the two
>    tokens are transferred from correspondent node to the next proxy
>    mobile node 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.  If
>    another proxy mobile agent is sending PBA on behalf of the
>    correspondent node, that proxy mobile agent SHOULD use its own CGA
>    property to protect PBA instead of the correspondent node's CGA
>    property.
> 
> 
> 
> Qin, et al.              Expires August 29, 2007               [Page 11]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
>          Proxy                                    Correspondent Node
>       Mobile Agent
>            |         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
> 
> 
> 4.  Route Optimization for Correspondent Nodes without Mobile IP
> 
>    This section describes route optimization procedure for correspondent
>    nodes which are not Mobile IP enabled.  Trigerring and scenario
>    analysis are made.  Two kinds of solutions are proposed: one without
>    return routability and the other with return routability.
> 
> 4.1.  Triggering and Scenario Analysis
> 
>    Route optimization in Mobile IPv6 is an end-to-end operation.  Once
>    mobile node and correspondent node complete the route optimization
>    procedure, all of communications between them will be optimized.  In
>    Proxy Mobile IP, however, proxy mobile agent is not the communication
>    end but an intermediary router.  Generally proxy mobile agent may not
>    be able to judge whether the packets need to be optimized or not.
>    So, it MAY be necessary to define a mechanism that allows mobile node
>    to inform the proxy mobile agent of its route optimization
>    requirement about its communication with the specific correspondent
>    node, or just let PMA to optimize all of the communications between
>    mobile node and other nodes.
> 
>    A flag could be defined to identify two route optimization trigger
>    modes: implicit mode that means that it's up to proxy mobile agent to
>    decide and perform route optimization for mobile node, or explicit
>    mode that means mobile node MUST send a message to trigger proxy
>    mobile agent to perform route optimization for mobile node.  The flag
>    of route optimization trigger mode can also be configured in a policy
>    store, such as in AAA infrastructure.  After successful access
>    authentication and authorization, proxy mobile agent gets this flag
>    as part of the user profile from AAA infrastructure.  On this point
>    route optimization can be considered as a kind of service that
> 
> 
> 
> Qin, et al.              Expires August 29, 2007               [Page 12]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
>    network provides to mobile users.
> 
>    Assuming that both mobile node and correspondent node are using Proxy
>    Mobile IPv6, there are four possible scenarios/cases due to the
>    different location of correspondent node: mobile node and
>    correspondent node attach to the same proxy mobile agent and they
>    belong to the same home agent (case 1), mobile node and correspondent
>    node attach to the same proxy mobile agent but they belong to
>    different home agents (case 2), mobile node and correspondent node
>    attach to different proxy mobile agents, but they have the same home
>    agent (case 3), mobile node and correspondent node attach to
>    different proxy mobile agents, and they have different home agents
>    (case 4).
> 
>    Cases 1 and 2 do not require any signaling between PMAs and packets
>    can be locally routed.  As mobile node and correspondent node both
>    attach to the same PMA and this PMA performs registration process on
>    behalf of them and maintains Binding Update List for them.  When PMA
>    receives the packets from mobile node or correspondent node, proxy
>    mobile agent SHOULD look up the Binding Update List to check whether
>    or not the destination IP address in the IP packet appears in the
>    Binding Update List as home address.  If yes, it means proxy mobile
>    agent has registered with home agent on behalf of destination node
>    and proxy mobile agent SHOULD directly forward the packet on the
>    connected interface instead of sending the packet to the home agent
>    through the bi-directional tunnel.
> 
>    In cases 3 and 4, mobile node and correspondent node attach to
>    different PMAs, the ideal data path is to directly go through these
>    two PMAs to which mobile node and correspondent node attach.  A bi-
>    directional tunnel needs to be established between these two proxy
>    mobile agents for route optimization.
> 
>    Proxy mobile agent needs to know IP address of the corresponding PMA
>    to which correspondent node attaches so that it can initiate the
>    route optimization signaling process.  HA of CN knows it because IP
>    address of corresponding PMA has been registered with the home agent
>    as the care-of address of CN.  Proxy mobile agent can send a request
>    to the home agent of CN and ask for the Binding Cache Entry for the
>    correspondent node if it knows the IP address of that home agent.
> 
>    Another method of obtaining PMAs' addresses is by exchanging them in
>    home test messages during return routability signaling.  Modified
>    PHoTI and PHoT messages can be used for this purpose.
> 
>    In Section 4.2 we present a route optimization technique based on
>    obtaining IP address of the corresponding PMA from the home agent and
>    in Section 4.3 based on return routability procedure.
> 
> 
> 
> Qin, et al.              Expires August 29, 2007               [Page 13]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
> 4.2.  Route Optimization without Return Routability
> 
>    A possible route optimization process is illustrated in Figure 6,
>    where PMA1 performs route optimization process for communication
>    between MN1 and CN4 whose corresponding PMA is PMA3 and HA is HA2.
>    After getting home agent address of CN4, PMA1 first sends the request
>    with home address of CN4 to HA2 to inquire the IP address of PMA3.
>    HA2 looks up the Binding Cache and responds with the care-of address
>    of CN4.
> 
>    PMA1 sends Proxy Binding Update to PMA3 to register the home address
>    of MN1 and IP address of PMA1 as care-of address with PMA3.  PMA3
>    stores this information in the Binding Cache entry for the MN1 and
>    responds with another Proxy Binding Update sent to PMA1 which
>    interprets it as an acknowledgement as well.  PMA1 sends Proxy
>    Binding Acknowledgement to PMA3 to confirm the registration request.
>    After this three-way handshake procedure, Binding Cache Entries for
>    MN1 and CN4 have been created in PMA3 and PMA1 respectively.  The
>    packets between MN1 and CN4 can go through the bi-directional tunnel
>    between PMA1 and PMA3 to reach each other.
> 
>       PMA1                           HA2        PMA3
>        |                              |           |
>        |  Binding Cache Request/Ack   |           |
>        |<---------------------------->|           |
>        |                              |           |
>        |                                          |
>        |           Proxy Binding Update           |
>        |----------------------------------------->|
>        |           Proxy Binding Update           |
>        |<-----------------------------------------|
>        |         Proxy Binding Acknowledgement    |
>        |----------------------------------------->|
>        |                                          |
> 
> 
>                          Figure 6: 3-way Handshake
> 
> 4.2.1.  Tunnel Re-establishment During the Handover
> 
>    Suppose a bi-directional tunnel has been established for route
>    optimization in case 4, handover happens when MN1 moves from PMA1 to
>    PMA2 and PMA2 registers with HA1 on behalf of MN1 after performing
>    access authentication Figure 7.  After the handover, PMA3 MUST be
>    informed of the mobility of MN1, or the packets from CN4 to MN1 will
>    still be sent to PMA1 because the Binding Cache Entry for MN1 hasn't
>    been updated in PMA3.  In fact, the one end of tunnel has changed
>    from PMA1 to PMA2 due to handover, and the tunnel MUST be re-
> 
> 
> 
> Qin, et al.              Expires August 29, 2007               [Page 14]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
>    established for route optimization.
> 
>                       +-----+                 +-----+
>                       | HA1 |~~~~~~~~~~~~~~~~~| HA2 |
>                      /+-----+\\               +-----+\\
>                     //        \\                      \\
>                    //          \\                      \\
>                   //            \\                      \\
>                  //              \\                      \\
>                 //                \\                      \\
>            +----+                  +----+               +----+
>            |PMA2|~~~~~~~~~~~~~~~~~~|PMA1|~~~~~~~~~~~~~~~|PMA3|
>            +--+-+                  +-+--+               +-+--+
>               |                      |                    |
>               |                      |                    |
>          -----+----              ----+-------          ---+--+--
>                                                              |
>                      +-----+                              +--+--+
>                <-----| MN1 |                              | CN4 |
>                      +-----+                              +-----+
> 
>                         Figure 7: Handover Scenario
> 
>    The context transfer of Binding Update List entry for mobile node can
>    trigger the new proxy mobile agent to re-establish the tunnel for
>    route optimization so that route optimized communication can continue
>    after handover.
> 
>    An example for route optimization signaling flow during handover is
>    depicted in Figure 8.  Here, the handover is controlled by network in
>    a reactive mode, where new proxy mobile agent (PMA2) sends Context
>    Transfer Request message to old proxy mobile agent (PMA1) and PMA1
>    responds with Context Transfer Data message which carries user
>    profiles and Binding Update List entries for MN1.  PMA2 SHOULD send
>    Proxy Binding Update message to corresponding proxy mobile agent
>    (PMA3 here) according to each Binding Update List entry.  The
>    following flow is the same as all that described in Section 4.2
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Qin, et al.              Expires August 29, 2007               [Page 15]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
>     PMA1                         PMA2                              PMA3
>      |                            |                                 |
>      |  Context Transfer Request  |                                 |
>      |<---------------------------|                                 |
>      |                            |                                 |
>      |  Context Transfer Data     |                                 |
>      |--------------------------->|                                 |
>      |                            |                                 |
>                                   |    Proxy Binding Update         |
>                                   |-------------------------------->|
>                                   |    Proxy Binding Update         |
>                                   |<--------------------------------|
>                                   |  Proxy Binding Acknowledgement  |
>                                   |-------------------------------->|
>                                   |                                 |
> 
>                          Figure 8: RO in Handover
> 
> 4.3.  Route Optimization with Return Routability
> 
>    If a proxy mobile agent provides mobility service for correspondent
>    nodes, PMIPv6 Route Optimization protocol could be used for such
>    correspondent nodes, as long as the proxy mobile agent intercepts and
>    processes route optimization extensions via looking over the MH types
>    and distinguishing Proxy Mobile IP signaling from data.  The process
>    is shown in Figure 9.  The proxy home test init message is
>    transmitted over the shared tunnel between proxy mobile agent of
>    mobile node and home agent of mobile node.  This proxy home test init
>    message is forwarded to home address of the correspondent node by HA.
>    At the home agent of the correspondent node, this message is
>    tunnelled into the shared tunnel between the home agent of
>    correspondent node and the proxy mobile agent of the correspondent
>    node.
> 
>    The proxy mobile agent of CN intercepts proxy home test init message
>    and extracts MN's home address and care-of address from PHoTI.  PMA
>    of CN sends a proxy home test message back to PMA of MN and adds
>    care-of address of CN into PHoT message.  PMA of CN creates a Binding
>    Cache entry for this MN.  PHoT is transmitted over the shared tunnel
>    between PMA of CN and HA of CN.  HA of CN forwards this message to
>    the home address of MN which tunnels it to PMA of MN.
> 
>    PMA of MN receives PHoT message, it extracts the care-of address of
>    CN and adds this information to the Binding Cache entry for CN.  PMA
>    of CN next starts care-of test signaling by sending an early binding
>    update message directly to the care-of address of CN, i.e. to PMA of
>    CN.
> 
> 
> 
> 
> Qin, et al.              Expires August 29, 2007               [Page 16]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
>    Due to the address exchange using PHoTI and PHoT messages, care-of
>    test signaling in Figure 9 MUST NOT be started in parallel to home
>    test signaling.
>       Proxy        Home Agent(MN)   Home Agent(CN)      Proxy
>    Mobile Agent(MN)                                Mobile Agent(CN)
>          |    Proxy HoTI  |               |                |
>          |===============>|-------------->|===============>|
>          |    Proxy HoT   |               |                |
>          |<===============|<--------------|<===============|
>          |   Early Proxy Binding Update   |                |
>          |------------------------------------------------>|
>          |   Proxy Binding Acknowledgement|                |
>          |<------------------------------------------------|
>          |   Complete Proxy Binding Update|                |
>          |------------------------------------------------>|
>          |   Proxy Binding Acknowledgement|                |
>          |<------------------------------------------------|
>          |                                |                |
> 
>     Figure 9: Route Optimization for Correspondent nodes without mobile
>                                     ip
> 
> 
> 5.  Home Agent Considerations
> 
>    The home agent MUST drop all HoTI messages received from a home
>    address that has corresponding Binding Cache entry with the proxy
>    registration flag set.  The home agent MUST forward all Proxy HoTI
>    messages received from a home address that has corresponding Binding
>    Cache entry with the proxy registration flag set.
> 
> 
> 6.  Proxy Mobile Agent Considerations
> 
>    PMA, after successful Home and Care-of Test exchanges, creates a
>    Binding Cache entry for the correspondent node or PMA of the
>    correspondent node.  For each mobile node, the Binding Cache contains
>    one entry for each correspondent node.  After handover, PMA deletes
>    the Binding Cache entry and deregisters MN with all its correspondent
>    nodes.
> 
>    PMA MUST maintain a Binding Update List for each MN.  The fields are
>    as defined in [2] and with extensions defined in [4].  For each MN
>    for which route optimization service is offered, the list in addition
>    MUST contain the private and public keys of MN.  Apart from home
>    registrations as in [4], Binding Update List contains correspondent
>    registrations for route optimization.
> 
> 
> 
> 
> Qin, et al.              Expires August 29, 2007               [Page 17]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
>    After handover, correspondent registration entries in the Binding
>    Update List SHOULD be transferred to the next PMA.  Such a transfer
>    provides continuity of correspondent registrations for route
>    optimization.  The next PMA refreshes such registrations only after
>    lifetime expiry.
> 
>    PMA MUST maintain a Binding Cache if it has Type 2 CNs.  Binding
>    cache entries are created when PMA receives a home test init message.
>    This Binding Cache is called Proxy Binding Cache.
> 
>    From the correspondent nodes PMA receives data packets with Type 2
>    routing header.  Type 2 routing header MUST conform to the structure
>    given in Section 6.1.5 of [2].  PMA MUST process the packet as
>    follows: PMA replaces the source address with the home address given
>    in Type 2 routing header.  PMA removes Type 2 routing header.  PMA
>    sends the packet to MN.
> 
>    PMA MUST not include IPv4 home address option [6] in proxy binding
>    updates sent for route optimization.  PMIPv6 route optimization for
>    dual-stack nodes is TBD.
> 
> 
> 7.  Correspondent Node Considerations
> 
>    This section state the differences in the behaviour of a
>    correspondent node that conforms to Section 9 of [2].
> 
>    Upon receiving a Proxy Home Test Init message, Early Proxy Binding
>    Update and Complete Proxy Binding Update message, the correspondent
>    node verifies the following: The packet MUST NOT include a Home
>    Address destination option.  The correspondent node MUST silently
>    ignore such packets.
> 
>    After a successful Home and Care-of Test exchanges, the correspondent
>    node creates a Binding Cache entry for the proxy mobile agent
>    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 PMA
>    encapsulated in IP-in-IP encapsulation.  Source address of the outer
>    header MUST be equal PMA'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 PMA.  The
>    destination address is PMA's egress interface address which serves as
>    Care-of address for the mobile node and the type 2 routing header
> 
> 
> 
> Qin, et al.              Expires August 29, 2007               [Page 18]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
>    contains MN's home address.
> 
> 
> 8.  Message Formats
> 
>    This section defines extensions to the Proxy Mobile IPv6 [4] protocol
>    messages and the enhanced route optimization in MIPv6 protocol
>    messages [5].
> 
> 8.1.  Proxy Home Test
>                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                        |       Home Nonce Index        |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        +                        Home Init Cookie                       +
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        +                        Home Keygen Token                      +
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +                        Care-of Address                        +
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        .                                                               .
>        .                        Mobility options                       .
>        .                                                               .
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>                               Proxy Home Test
> 
>    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 PMA.
>    For descriptions of other fields present in this message, refer to
>    section 6.1.5 in [2].
> 
> 
> 
> Qin, et al.              Expires August 29, 2007               [Page 19]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
> 8.2.  Proxy Home Test Init Message
>                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                        |           Reserved            |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        +                       Home Init Cookie                        +
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +                        Care-of Address                        +
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        .                                                               .
>        .                       Mobility Options                        .
>        .                                                               .
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>                            Proxy Home Test Init
> 
>    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 PMA.
>    For descriptions of other fields present in this message, refer to
>    section 6.1.5 in [2].
> 
> 8.3.  Handover Home Keygen Token option
> 
>    Handover home keygen token is a mobility option.  It is sent by CN in
>    proxy binding acknowledgement message.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Qin, et al.              Expires August 29, 2007               [Page 20]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
>         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                   :
>        :                                                               :
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>                      Handover Home Keygen Token option
> 
>    Option Type
>       8-bit identifier of the type of this mobility option.  Its value
>       is TBD.
> 
>    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 proxy mobile agent'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.
> 
> 
> 9.  Security Considerations
> 
>    Security mechanism is very important in the route optimization
>    process, especially for the proposal of establishing the tunnel
>    between two proxy mobile agents.  In the case of route optimization
>    without return routability, if proxy mobile agent does not
>    authenticate Proxy Binding Update and Proxy Binding Acknowledge
>    messages, a malicious node may send such signaling messages to proxy
>    mobile agents to get the data packets destined for other nodes
>    directed to itself.
> 
>    In addition, when proxy mobile agent sends data packets through the
>    bi-directional tunnel between two proxy mobile agents, corresponding
>    PMA SHOULD examine the data packets to make sure there is a Binding
>    Cache entry for the data source terminal.
> 
>    Route optimization signaling between PMA of MN and CN specified in
>    this document is based on [5] and use return routability with better
>    security properties than the return routability of the base protocol
> 
> 
> 
> Qin, et al.              Expires August 29, 2007               [Page 21]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
>    [2].
> 
>    Return routability signaling between two PMAs specified in this
>    document is also based on [5] and has better security properties.
> 
> 
> 10.  References
> 
> 10.1.  Normative References
> 
>    [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
>         Levels", BCP 14, RFC 2119, March 1997.
> 
>    [2]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
>         IPv6", RFC 3775, June 2004.
> 
>    [3]  Aura, T., "Cryptographically Generated Addresses (CGA)",
>         RFC 3972, March 2005.
> 
>    [4]  Gundavelli, S., "Proxy Mobile IPv6",
>         draft-sgundave-mip6-proxymip6-01 (work in progress),
>         January 2007.
> 
>    [5]  Arkko, J., "Enhanced Route Optimization for Mobile IPv6",
>         draft-ietf-mipshop-cga-cba-03 (work in progress), February 2007.
> 
> 10.2.  Informative references
> 
>    [6]  Soliman, H., "Mobile IPv6 support for dual stack Hosts and
>         Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-03 (work in
>         progress), October 2006.
> 
> 
> Authors' Addresses
> 
>    Alice Qin
>    Huawei Technologies
>    No.91 BaiXia Rd.
>    Nanjing, Jiangsu  210001
>    China
> 
>    Email: [email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Qin, et al.              Expires August 29, 2007               [Page 22]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 2007
> 
> 
>    Andy Huang
>    Huawei Technologies
>    No.91 BaiXia Rd.
>    Nanjing, Jiangsu  210001
>    China
> 
>    Phone: +86-25-84565457
>    Email: [email-masked]
> 
> 
>    Wenson Wu
>    Huawei Technologies
>    No.91 BaiXia Rd.
>    Nanjing, Jiangsu  210001
>    China
> 
>    Phone: +86-25-84565459
>    Email: [email-masked]
> 
> 
>    Behcet Sarikaya
>    Huawei Technologies
>    1700 Alma Dr. Suite 100
>    Plano, TX  75075
> 
>    Email: [email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Qin, et al.              Expires August 29, 2007               [Page 23]
> 
> Internet-Draft          PMIPv6 Route Optimization          February 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
>    [email-masked].
> 
> 
> Acknowledgment
> 
>    Funding for the RFC Editor function is provided by the IETF
>    Administrative Support Activity (IASA).
> 
> 
> 
> 
> 
> Qin, et al.              Expires August 29, 2007               [Page 24]
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm

-- 
Jun Lei
PhD Student

Address:
Georg-August-Universitaet Goettingen
Institut fuer Informatik
Telematics Group
Lotzestrasse 16-18
37083 Goettingen

Fax: +49 (551) 39-1 44 03
Tel: +49 (551) 39-1 35 78

Email: [email-masked]

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: qinxia <[email-masked]>
Date: Wed, 18 Apr 2007 11:13:46 +0800

Hello Lei,

         Thanks for your comments! Please kindly see inlines.
Best wishes
Alice  

> -----Original Message-----
> From: Jun Lei [mailto:[email-masked]] 
> Sent: Tuesday, April 17, 2007 4:45 PM
> To: qinxia
> Cc: [email-masked]
> Subject: Re: [netlmm] Welcome your comments on 

[qx] yes, as I said on presentation.

> methods? At least, the mechanism described here is not clear to me.
[qx] as CN is behind a PMA(MAG), who and how to decide RO with whom? This problem
needs to be researched further. If you have good ideas, please let me know.

> temporary home keygen token and care of keygen token? And 
[qx] temporary home keygen token is defined in "enhanced route optimization for
MIPv6" . I did not repeat it in my draft.
If people think it is necessary to repeat it, I will append it.
> The description of the figure 4 is not very explicitly clear.
[qx] ok, I will fix it in the revision. Thanks.

> doesn't hold the permanent home keygen token. Is that right?

[qx] if PMA has no permanent home keygen token, or the token is needed to be updated,
then these tokens should be generated.

> please give a scenario, which might be helpful.

[qx] inter-domain? I did not find this word in this draft,  could you point it out?
Thanks.
> > Internet-Draft                                              
>     A. Huang
> >                                                      Huawei 
> Technologies
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> >             |   Handover context     |                      
> >             |home keygen token)      |                      
> >    handover \\                       \\                     
> |----------------------------->|
> >             |                        |  Proxy Binding 
> Acknowledge   |
> >             |                        
> |<-----------------------------|
> >             |                        | Complete Proxy 
> Binding Update|
> >             |                        
> |----------------------------->|
> >             |                        |Proxy Binding 
> Acknowledge     |
> >             |                        
> |<-----------------------------|
> >             |                        |(new Permanent,       
>         |
> >             |                        |Handover home keygen 
> token)   |
> >             |                        |                      
>         |
> > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> >     PMA1                         PMA2                       
>        PMA3
> >                                   |    Proxy Binding Update 
> >                                   |    Proxy Binding Update 
> > > 
> > > 
> > > 
> >                                        |       Home Nonce 
> Index        |
> >        +                        Home Init Cookie            
>            +
> >        +                        Home Keygen Token           
>            +
> >        +                                                    
>            +
> >        +                        Care-of Address             
>            +
> >        +                                                    
>            +
> >        .                                                    
>            .
> >        .                        Mobility options            
>            .
> >        .                                                    
>            .
> > > 
> >                                        |           Reserved 
> >        +                       Home Init Cookie             
>            +
> >        +                                                    
>            +
> >        +                        Care-of Address             
>            +
> >        +                                                    
>            +
> >        .                                                    
>            .
> >        .                       Mobility Options             
>            .
> >        .                                                    
>            .
> > > 
> >         0                   1                   2           
>         3
> >        :                                                    
>            :
> >        :                                                    
>            :
> > > 
> >         Routers (DSMIPv6)", 
> draft-ietf-mip6-nemo-v4traversal-03 (work in
> >         progress), October 2006.
> > 
> > 
> > Authors' Addresses
> > 
> >    Alice Qin
> >    Huawei Technologies
> >    No.91 BaiXia Rd.
> >    Nanjing, Jiangsu  210001
> >    China
> > 
> > > 
> > >

---

From: Jun Lei <[email-masked]>
Date: Wed, 18 Apr 2007 11:44:39 +0200

Dear Alice,

Thanks for your quick response. Please see inline.
> [qx] yes, as I said on presentation. 

Good.
> needs to be researched further. If you have good ideas, please let me know. 

[Jun] Right. I've seen this big issue through the draft. Currently, the 
way, from my side, would be two sides.

One is acceptance of RO for all CN. Another is performing RO to specific 
CN. Regarding the second one, PMA might be the only guy to do this....I 
will think about it and if any idea comes out of my mind, I will let you 
know.

> If people think it is necessary to repeat it, I will append it.
[Jun] Fair. However, please add at least a reference with the coming 
word "temporary home...". Otherwise, the readers will be confused.
> [qx] ok, I will fix it in the revision. Thanks.

[Jun] Good.
> then these tokens should be generated.

[Jun] Could you then explain briefly how to generate this permanent home 
keygen token in this case? or give a example because you mentioned that 
it would be generated by using PMA's public key.
> [qx] inter-domain? I did not find this word in this draft,  could you point it out?

[Jun] Since it is hardly to find in the draft that the mechanism only 
supports the MN roams within PMIP domain, I assumed that it also 
supports inter-domain roaming. Maybe I am wrong.

Cheers

Jun
>>>   This document defines route optimization protocol for 
>>
>>Proxy Mobile     
>>
>>>   IPv6.  Proxy home test, concurrent proxy care-of test 
>>
>>and handover     
>>
>>>   procedures are explained.  Proxy mobile agent 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 
>>
>>proxy mobile     
>>
>>>   agent.  A different route optimization protocol is 
>>
>>defined for inter-  
>>
>>>   proxy mobile agent operation if the correspondent node 
>>
>>is not Mobile   
>>
>>>   IPv6 enabled.                                            
>>
>>              
>>
>>>
>>>Network Working Group                                       
>>      A. Qin
>>>Expires: August 29, 2007                                    
>>       W. Wu
>>>   By submitting this Internet-Draft, each author 
>>
>>represents that any
>>
>>>   have been or will be disclosed, and any of which he or 
>>
>>she becomes
>>
>>>   Internet-Drafts are draft documents valid for a maximum 
>>
>>of six months
>>
>>>   and may be updated, replaced, or obsoleted by other 
>>
>>documents at any
>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>    [Page 1]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>Abstract
>>>
>>>   This document defines route optimization protocol for 
>>
>>PMIPv6.  Proxy
>>
>>>   home test, concurrent proxy care-of test and handover 
>>
>>procedures are
>>
>>>   explained.  Proxy mobile agent 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
>>
>>>   route optimization protocol is defined for inter-proxy 
>>
>>mobile agent
>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>    [Page 2]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>1.  Introduction
>>>
>>>   In Proxy Mobile IPv6 (PMIPv6) scheme, the mobility is 
>>
>>transparent to
>>
>>>   mobile nodes (MN) by the Proxy Mobility Agent (PMA) 
>>
>>simulating a home
>>
>>>   transparent to correspondent nodes (CN) by forcing all 
>>
>>datagrams for
>>
>>>   datagrams to the mobile node are often routed along 
>>
>>paths that are
>>
>>>   significantly longer than optimal.  However, packets 
>>
>>could be routed
>>
>>>   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 [4] 
>>
>>and Enhanced
>>
>>>   Route Optimization for Mobile IPv6 [5], to securely 
>>
>>establish optimal
>>
>>>   route path between PMA and correspondent nodes or 
>>
>>between two PMAs.
>>
>>>   RFC3775 and recognize PMIPv6 messages, correspondent 
>>
>>nodes without
>>
>>>   Mobile IPv6, as well as a fixed correspondent node 
>>
>>without mobility.
>>
>>>   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
>>
>>>   Some terminology is defined in Section 2.  Section 3 
>>
>>presents PMIPv6
>>
>>>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
>>
>>"SHALL NOT",
>>
>>>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
>>
>>"OPTIONAL" in this
>>
>>>      router, which is defined in [4].  In PMIPv6, proxy 
>>
>>mobile agent
>>
>>>      acts an Mobile Ip client agent of MN.  In this 
>>
>>document, the route
>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>    [Page 3]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>   Proxy Binding Cache
>>>      proxy mobile agent for use in sending or forwarding 
>>
>>datagrams to
>>
>>>      A cryptographically generated home address enables 
>>
>>correspondent
>>
>>>      nodes to securely authenticate the owner of home 
>>
>>address (HoA), by
>>
>>>      From the perspective of correspondent node, the home 
>>
>>address of
>>
>>>      optimization procedure.  In this document, proxy 
>>
>>mobile IPv6 home
>>
>>>      addresses are cryptographically generated home 
>>
>>addresses using its
>>
>>>      mobile node's public key.  Home prefix could be 
>>
>>per-MN prefix or
>>
>>>      shared prefix.
>>>      correspondent node for a mobile node, is exchanged 
>>
>>between proxy
>>
>>>      token is kept by proxy mobile agent.  The permanent 
>>
>>home keygen
>>
>>>      permanent home keygen token is renewed as soon as the 
>>
>>mobile node
>>
>>>      moves to the next proxy mobile agent.  Since the 
>>
>>lifetime of proxy
>>
>>>      binding update is due, permanent home keygen token 
>>
>>should be re-
>>
>>>      generated too.
>>>      A secret handover home keygen token is used during 
>>
>>handover, which
>>
>>>      is generated by a correspondent node for a mobile 
>>
>>node.  Handover
>>
>>>      home keygen token, kept by proxy mobile agent, is 
>>
>>obtained along
>>
>>>      will be not out-of-date even though the registration 
>>
>>lifetime is
>>
>>>      due.  During handover, handover home keygen token is 
>>
>>transferred
>>
>>>      A node that is Mobile IPv6 enabled to be a 
>>
>>correspondent node as
>>
>>>      provides both mobility and route optimization 
>>
>>services to Type 2
>>
>>>      CNs.
>>>
>>>
>>>
>>>
>>>
>>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>    [Page 4]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>   This section consists of a set of approaches to meet 
>>
>>requirements of
>>
>>>   This protocol is based on PMIPv6 and Enhanced Route 
>>
>>Optimization for
>>
>>>   Mobile IPv6.
>>>
>>>   Once a mobile node enters its Proxy Mobile IPv6 domain, 
>>
>>proxy mobile
>>
>>>   signaling on behalf of the mobile node.  In MIPv6, a 
>>
>>mobile node may
>>
>>>   determine when and which correspondent node needs route 
>>
>>optimization.
>>
>>>   In contrast, access router MAY inform proxy mobile agent 
>>
>>to initiate
>>
>>>   route optimization procedure according to some policies 
>>
>>in PMIPv6.
>>
>>>   As soon as proxy mobile agent makes decision on which 
>>
>>correspondent
>>
>>>   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 proxy mobile 
>>
>>agent 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 proxy mobile agent, 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
>>
>>>   keygen token via this round trip of proxy binding update 
>>
>>exchange.
>>
>>>   exchange.  Thus, the correspondent node MAY authenticate 
>>
>>this proxy
>>
>>>   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
>>
>>>   During handover, the next proxy mobile agent 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 
>>
>>rachability
>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>    [Page 5]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>   In PMIPv6 route optimization protocol, the proxy home 
>>
>>test and proxy
>>
>>>   care-of test exchanges are initiated by PMA instead of 
>>
>>MN.  However,
>>
>>>   destination address of proxy home test message are home 
>>
>>address of
>>
>>>   mobile node.  So, the proxy mobile agent MUST identify, 
>>
>>intercept and
>>
>>>   For the sake of security, cryptographically generated 
>>
>>home addresses
>>
>>>   and permanent home keygen token, defined in [5], 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 PMA the 
>>
>>mobile node
>>
>>>   visits.  The input parameters to the CGA calculations 
>>
>>[3] like the
>>
>>>   subnet prefix, public key and private key are available 
>>
>>to each PMA.
>>
>>>   One possible mechanism is context transfer from the 
>>
>>previous PMA.  In
>>
>>>   As shown in Figure 1, the optimal route path is depicted 
>>
>>by slashes
>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>    [Page 6]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>   Proxy Home Test procedure validates the home address.  
>>
>>It includes
>>
>>>   two messages as follows:
>>>
>>>   reachability of home address.  The next proxy mobile 
>>
>>agent MAY also
>>
>>>   correspondent nodes list in its Binding Update List.  
>>
>>When MN roams
>>
>>>   transferred to the next PMA using context transfer 
>>
>>protocol or other
>>
>>>   Binding Update List on MN identity like NAI, private and 
>>
>>public keys,
>>
>>>   etc.  SHOULD be transferred to the next PMA.  The 
>>
>>context transfer
>>
>>>   As shown in Figure 2, the proxy mobile agent imitates 
>>
>>the Mobile IP
>>
>>>   client of the mobile node.  The Proxy Home Test Init 
>>
>>(PHoTI) message
>>
>>>    Proxy Mobile Agent                 Home agent    
>>
>>Correspondent node
>>
>>>        Decide to optimize route path       |               
>>
>>        |
>>
>>>           |                                |               
>>
>>        |
>>
>>>           |==Proxy Home Test Init 
>>
>>(PHoTI)=>|---------------------->|
>>
>>>           |                                |               
>>
>>        |
>>
>>>           |                                |               
>>
>>        |
>>
>>>           |<====Proxy Home Test 
>>
>>(PHoT)=====|<----------------------|
>>
>>>           |                                |               
>>
>>        |
>>
>>>   Correspondent nodes also need to prove the reachability 
>>
>>of care-of
>>
>>>   address.  In this document, since the care-of test is 
>>
>>initiated by
>>
>>>   care-of test procedure in order to differentiate the 
>>
>>procedure from
>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>    [Page 7]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>   Proxy care-of test is piggybacked on a proxy binding 
>>
>>update which is
>>
>>>   sent by proxy mobile agent on behalf of the mobile node 
>>
>>to register
>>
>>>   with proxy binding update exchange, so we call it 
>>
>>concurrent proxy
>>
>>>   care-of test.  As shown in Figure 3, as a correspondent 
>>
>>node receives
>>
>>>   care-of keygen token in care-of test option piggybacked 
>>
>>onto proxy
>>
>>>   binding acknowledgement (PBA) message.  The mechanism is 
>>
>>as described
>>
>>>   in [5].
>>>
>>>   After the first round trip of proxy binding update 
>>
>>exchange is over
>>
>>>   packets directly to care-of address of the mobile node 
>>
>>even though
>>
>>>   the care-of address is not verified.  However, the proxy 
>>
>>mobile agent
>>
>>>   update exchange.  The proxy mobile agent may initiate 
>>
>>another proxy
>>
>>>   keygen token and care-of keygen token, and then it makes 
>>
>>sure that
>>
>>>   the proxy binding cache entry created by early proxy 
>>
>>binding update
>>
>>>   based flooding attacks, Credit-Based Authorization is 
>>
>>also exploited,
>>
>>>   If proxy mobile agent has only temporary home keygen 
>>
>>token instead of
>>
>>>   permanent home keygen token, the proxy mobile agent 
>>
>>calculates the
>>
>>>   Binding Authorization Data option field of early proxy 
>>
>>binding update
>>
>>>   which is set to ZERO.  Proxy mobile agent calculates CGA 
>>
>>parameters
>>
>>>   and signature option according to MN's home address and 
>>
>>private and
>>
>>>   public keys to be sent in a proxy binding update message 
>>
>>to acquire
>>
>>>   If proxy mobile agent has permanent home keygen token, 
>>
>>proxy mobile
>>
>>>   agent calculates the Binding Authorization Data option 
>>
>>field of early
>>
>>>   keygen token which is set to ZERO.  No CGA parameters 
>>
>>and signature
>>
>>>   are required.
>>>
>>>   If proxy mobile agent has only handover home keygen 
>>
>>token, the proxy
>>
>>>   mobile agent calculates the Binding Authorization Data 
>>
>>option field
>>
>>>   of early proxy binding update message with handover home 
>>
>>keygen token
>>
>>>   mobile agent must include MN's CGA parameters and 
>>
>>signature in this
>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>    [Page 8]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>   concurrent proxy care-of test is piggybacked onto early 
>>
>>proxy binding
>>
>>>   binding update based on handover home keygen token if 
>>
>>the next proxy
>>
>>>   proceeds concurrently.  The amount of data, which the 
>>
>>correspondent
>>
>>>   verification completes, is governed by Credit-Based 
>>
>>Authorization.
>>
>>>   If the previous proxy mobile agent forecasts the 
>>
>>forthcoming handover
>>
>>>   of mobile node via layer 2 indication, such as link 
>>
>>going down event
>>
>>>   in the Media-Independent Handover, the previous proxy 
>>
>>mobile agent
>>
>>>   could help the next proxy mobile agent to pass the 
>>
>>verification of
>>
>>>   home address required by correspondent nodes.  The next 
>>
>>proxy mobile
>>
>>>   agent MAY fetch the handover home keygen token through 
>>
>>home agent via
>>
>>>   proxy binding update exchanges with the home agent of 
>>
>>mobile node.
>>
>>>   previous proxy mobile agent deregisters the proxy 
>>
>>binding cache entry
>>
>>>   with correspondent nodes.  The correspondent node 
>>
>>revokes permanent
>>
>>>   As depicted in Figure 4, after the next proxy mobile 
>>
>>agent obtains
>>
>>>
>>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>    [Page 9]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>   unverified in the correspondent node.  As soon as the 
>>
>>complete proxy
>>
>>>   agent's public key and private key to request care-of 
>>
>>keygen token.
>>
>>>   property.  If the proxy binding update passes the 
>>
>>verification, the
>>
>>>   correspondent node returns a care-of keygen token which 
>>
>>is encrypted
>>
>>>   with the next proxy mobile agent's public key.  The 
>>
>>care-of keygen
>>
>>>   message as a field.  As soon as the next proxy mobile 
>>
>>agent receives
>>
>>>   this proxy binding acknowledgement, it sends a complete 
>>
>>proxy binding
>>
>>>   calculated using both care-of keygen token and handover 
>>
>>home keygen
>>
>>>   token.
>>>
>>>         Previous                     Next               
>>
>>Correspondent
>>
>>>            |----------------------->|                      
>>
>>        |
>>
>>>            |(HoA,CN address,handover|                      
>>
>>        |
>>
>>>            |home keygen token)      |                      
>>
>>        |
>>
>>>   handover \\                       \\                     
>>
>>        |
>>
>>>            |  Proxy binding update(lifetime = 0)           
>>
>>        |
>>
>>>            
>>
>>>            |          Proxy binding Acknowledge (if sent)  
>>
>>        |
>>
>>>            
>>
>>>            |                        | Early Proxy Binding 
>>Update   |
>>>            |                        |  Proxy Binding 
>>Acknowledge   |
>>>            |                        | Complete Proxy 
>>Binding Update|
>>>            |                        |Proxy Binding 
>>Acknowledge     |
>>>            |                        |Handover home keygen 
>>token)   |
>>>Qin, et al.              Expires August 29, 2007            
>>
>>   [Page 10]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>   A complete proxy binding update is a proxy binding 
>>
>>update defined in
>>
>>>   brought forward.  The Binding Authorization Data option 
>>
>>field of it
>>
>>>   legitimacy of the PMA which is sending this message on 
>>
>>behalf of MN.
>>
>>>   update exchange follows Figure 5.  PBU message must be 
>>
>>sent with CGA
>>
>>>   parameters and signature option for the proxy mobile 
>>
>>agent to request
>>
>>>   permanent home keygen token and handover home keygen 
>>
>>token from the
>>
>>>   interface identifier and the CGA owner's public key.  
>>
>>This enables
>>
>>>   other nodes to securely authenticate the CGA owner.  
>>
>>Depending on the
>>
>>>   addresses, lifetime of binding is extended to a longer 
>>
>>period more
>>
>>>   than 7 minutes [2].  Except for the initial test, the 
>>
>>following home
>>
>>>   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 proxy mobile agent has only temporary 
>>
>>home keygen
>>
>>>   If the proxy mobile agent has permanent home keygen 
>>
>>token, the proxy
>>
>>>   If the permanent home keygen token is required, both 
>>
>>permanent home
>>
>>>   encrypted with the proxy mobile agent's public key.  
>>
>>Both of the two
>>
>>>   complete proxy binding update message.  This new 
>>
>>handover home keygen
>>
>>>   The PBA MAY be protected by CGA property of 
>>
>>correspondent nodes.  If
>>
>>>   correspondent node, that proxy mobile agent SHOULD use 
>>
>>its own CGA
>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>   [Page 11]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>         Proxy                                    Correspondent Node
>>>      Mobile Agent
>>>   This section describes route optimization procedure for 
>>
>>correspondent
>>
>>>   analysis are made.  Two kinds of solutions are proposed: 
>>
>>one without
>>
>>>   Route optimization in Mobile IPv6 is an end-to-end 
>>
>>operation.  Once
>>
>>>   mobile node and correspondent node complete the route 
>>
>>optimization
>>
>>>   procedure, all of communications between them will be 
>>
>>optimized.  In
>>
>>>   Proxy Mobile IP, however, proxy mobile agent is not the 
>>
>>communication
>>
>>>   end but an intermediary router.  Generally proxy mobile 
>>
>>agent may not
>>
>>>   So, it MAY be necessary to define a mechanism that 
>>
>>allows mobile node
>>
>>>   requirement about its communication with the specific 
>>
>>correspondent
>>
>>>   node, or just let PMA to optimize all of the 
>>
>>communications between
>>
>>>   A flag could be defined to identify two route 
>>
>>optimization trigger
>>
>>>   modes: implicit mode that means that it's up to proxy 
>>
>>mobile agent to
>>
>>>   decide and perform route optimization for mobile node, 
>>
>>or explicit
>>
>>>   mobile agent to perform route optimization for mobile 
>>
>>node.  The flag
>>
>>>   of route optimization trigger mode can also be 
>>
>>configured in a policy
>>
>>>   authentication and authorization, proxy mobile agent 
>>
>>gets this flag
>>
>>>   as part of the user profile from AAA infrastructure.  On 
>>
>>this point
>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>   [Page 12]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>   Assuming that both mobile node and correspondent node 
>>
>>are using Proxy
>>
>>>   belong to the same home agent (case 1), mobile node and 
>>
>>correspondent
>>
>>>   different home agents (case 2), mobile node and 
>>
>>correspondent node
>>
>>>   attach to different proxy mobile agents, but they have 
>>
>>the same home
>>
>>>   different proxy mobile agents, and they have different 
>>
>>home agents
>>
>>>   (case 4).
>>>
>>>   Cases 1 and 2 do not require any signaling between PMAs 
>>
>>and packets
>>
>>>   can be locally routed.  As mobile node and correspondent 
>>
>>node both
>>
>>>   attach to the same PMA and this PMA performs 
>>
>>registration process on
>>
>>>   behalf of them and maintains Binding Update List for 
>>
>>them.  When PMA
>>
>>>   receives the packets from mobile node or correspondent 
>>
>>node, proxy
>>
>>>   mobile agent SHOULD look up the Binding Update List to 
>>
>>check whether
>>
>>>   Binding Update List as home address.  If yes, it means 
>>
>>proxy mobile
>>
>>>   agent has registered with home agent on behalf of 
>>
>>destination node
>>
>>>   connected interface instead of sending the packet to the 
>>
>>home agent
>>
>>>   different PMAs, the ideal data path is to directly go 
>>
>>through these
>>
>>>   two PMAs to which mobile node and correspondent node 
>>
>>attach.  A bi-
>>
>>>   directional tunnel needs to be established between these 
>>
>>two proxy
>>
>>>   Proxy mobile agent needs to know IP address of the 
>>
>>corresponding PMA
>>
>>>   route optimization signaling process.  HA of CN knows it 
>>
>>because IP
>>
>>>   address of corresponding PMA has been registered with 
>>
>>the home agent
>>
>>>   as the care-of address of CN.  Proxy mobile agent can 
>>
>>send a request
>>
>>>   to the home agent of CN and ask for the Binding Cache 
>>
>>Entry for the
>>
>>>   Another method of obtaining PMAs' addresses is by 
>>
>>exchanging them in
>>
>>>   obtaining IP address of the corresponding PMA from the 
>>
>>home agent and
>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>   [Page 13]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>   between MN1 and CN4 whose corresponding PMA is PMA3 and 
>>
>>HA is HA2.
>>
>>>   After getting home agent address of CN4, PMA1 first 
>>
>>sends the request
>>
>>>   with home address of CN4 to HA2 to inquire the IP 
>>
>>address of PMA3.
>>
>>>   HA2 looks up the Binding Cache and responds with the 
>>
>>care-of address
>>
>>>   of CN4.
>>>
>>>   PMA1 sends Proxy Binding Update to PMA3 to register the 
>>
>>home address
>>
>>>   stores this information in the Binding Cache entry for 
>>
>>the MN1 and
>>
>>>   Binding Acknowledgement to PMA3 to confirm the 
>>
>>registration request.
>>
>>>   After this three-way handshake procedure, Binding Cache 
>>
>>Entries for
>>
>>>   packets between MN1 and CN4 can go through the 
>>
>>bi-directional tunnel
>>
>>>   optimization in case 4, handover happens when MN1 moves 
>>
>>from PMA1 to
>>
>>>   PMA2 and PMA2 registers with HA1 on behalf of MN1 after 
>>
>>performing
>>
>>>   informed of the mobility of MN1, or the packets from CN4 
>>
>>to MN1 will
>>
>>>   still be sent to PMA1 because the Binding Cache Entry 
>>
>>for MN1 hasn't
>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>   [Page 14]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>   The context transfer of Binding Update List entry for 
>>
>>mobile node can
>>
>>>   route optimization so that route optimized communication 
>>
>>can continue
>>
>>>   after handover.
>>>
>>>   An example for route optimization signaling flow during 
>>
>>handover is
>>
>>>   depicted in Figure 8.  Here, the handover is controlled 
>>
>>by network in
>>
>>>   a reactive mode, where new proxy mobile agent (PMA2) 
>>
>>sends Context
>>
>>>   Transfer Request message to old proxy mobile agent 
>>
>>(PMA1) and PMA1
>>
>>>   profiles and Binding Update List entries for MN1.  PMA2 
>>
>>SHOULD send
>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>   [Page 15]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>    PMA1                         PMA2                       
>>
>>       PMA3
>>
>>>     |                            |                         
>>
>>        |
>>
>>>     |  Context Transfer Request  |                         
>>
>>        |
>>
>>>     |<---------------------------|                         
>>
>>        |
>>
>>>     |                            |                         
>>
>>        |
>>
>>>     |  Context Transfer Data     |                         
>>
>>        |
>>
>>>     |--------------------------->|                         
>>
>>        |
>>
>>>     |                            |                         
>>
>>        |
>>
>>>                                  |    Proxy Binding Update 
>>
>>        |
>>
>>>                                  
>>
>>>                                  |  Proxy Binding 
>>Acknowledgement  |
>>>   If a proxy mobile agent provides mobility service for 
>>
>>correspondent
>>
>>>   correspondent nodes, as long as the proxy mobile agent 
>>
>>intercepts and
>>
>>>   processes route optimization extensions via looking over 
>>
>>the MH types
>>
>>>   and distinguishing Proxy Mobile IP signaling from data.  
>>
>>The process
>>
>>>   mobile node and home agent of mobile node.  This proxy 
>>
>>home test init
>>
>>>   message is forwarded to home address of the 
>>
>>correspondent node by HA.
>>
>>>   correspondent node and the proxy mobile agent of the 
>>
>>correspondent
>>
>>>   node.
>>>
>>>   The proxy mobile agent of CN intercepts proxy home test 
>>
>>init message
>>
>>>   and extracts MN's home address and care-of address from 
>>
>>PHoTI.  PMA
>>
>>>   care-of address of CN into PHoT message.  PMA of CN 
>>
>>creates a Binding
>>
>>>   Cache entry for this MN.  PHoT is transmitted over the 
>>
>>shared tunnel
>>
>>>   between PMA of CN and HA of CN.  HA of CN forwards this 
>>
>>message to
>>
>>>   PMA of MN receives PHoT message, it extracts the care-of 
>>
>>address of
>>
>>>   CN and adds this information to the Binding Cache entry 
>>
>>for CN.  PMA
>>
>>>   of CN next starts care-of test signaling by sending an 
>>
>>early binding
>>
>>>   update message directly to the care-of address of CN, 
>>
>>i.e. to PMA of
>>
>>>   CN.
>>>
>>>
>>>
>>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>   [Page 16]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>   Due to the address exchange using PHoTI and PHoT 
>>
>>messages, care-of
>>
>>>   test signaling in Figure 9 MUST NOT be started in 
>>
>>parallel to home
>>
>>>   test signaling.
>>>    Figure 9: Route Optimization for Correspondent nodes 
>>
>>without mobile
>>
>>>                                    ip
>>>
>>>
>>>   registration flag set.  The home agent MUST forward all 
>>
>>Proxy HoTI
>>
>>>   messages received from a home address that has 
>>
>>corresponding Binding
>>
>>>   correspondent node.  For each mobile node, the Binding 
>>
>>Cache contains
>>
>>>   one entry for each correspondent node.  After handover, 
>>
>>PMA deletes
>>
>>>   the Binding Cache entry and deregisters MN with all its 
>>
>>correspondent
>>
>>>   nodes.
>>>
>>>   PMA MUST maintain a Binding Update List for each MN.  
>>
>>The fields are
>>
>>>   as defined in [2] and with extensions defined in [4].  
>>
>>For each MN
>>
>>>   for which route optimization service is offered, the 
>>
>>list in addition
>>
>>>   registrations as in [4], Binding Update List contains 
>>
>>correspondent
>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>   [Page 17]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>   Update List SHOULD be transferred to the next PMA.  Such 
>>
>>a transfer
>>
>>>   optimization.  The next PMA refreshes such registrations 
>>
>>only after
>>
>>>   lifetime expiry.
>>>
>>>   cache entries are created when PMA receives a home test 
>>
>>init message.
>>
>>>   From the correspondent nodes PMA receives data packets 
>>
>>with Type 2
>>
>>>   routing header.  Type 2 routing header MUST conform to 
>>
>>the structure
>>
>>>   follows: PMA replaces the source address with the home 
>>
>>address given
>>
>>>   in Type 2 routing header.  PMA removes Type 2 routing 
>>
>>header.  PMA
>>
>>>   sends the packet to MN.
>>>
>>>   PMA MUST not include IPv4 home address option [6] in 
>>
>>proxy binding
>>
>>>   updates sent for route optimization.  PMIPv6 route 
>>
>>optimization for
>>
>>>   dual-stack nodes is TBD.
>>>
>>>
>>>   Upon receiving a Proxy Home Test Init message, Early 
>>
>>Proxy Binding
>>
>>>   Update and Complete Proxy Binding Update message, the 
>>
>>correspondent
>>
>>>   After a successful Home and Care-of Test exchanges, the 
>>
>>correspondent
>>
>>>   expiration of its lifetime or after receiving a proxy 
>>
>>binding update
>>
>>>   Correspondent node MUST receive route optimized data 
>>
>>packets from PMA
>>
>>>   encapsulated in IP-in-IP encapsulation.  Source address 
>>
>>of the outer
>>
>>>   header MUST be equal PMA's egress interface address and 
>>
>>MUST match
>>
>>>   CN MUST use Type 2 routing header in outgoing packets to 
>>
>>PMA.  The
>>
>>>   destination address is PMA's egress interface address 
>>
>>which serves as
>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>   [Page 18]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>   This section defines extensions to the Proxy Mobile IPv6 
>>
>>[4] protocol
>>
>>>      This field contains the 64 bit temporary home keygen 
>>
>>token used to
>>
>>>      This field contains the care-of address assigned to 
>>
>>the CN by PMA.
>>
>>>   For descriptions of other fields present in this 
>>
>>message, refer to
>>
>>>   section 6.1.5 in [2].
>>>
>>>
>>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>   [Page 19]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>   For descriptions of other fields present in this 
>>
>>message, refer to
>>
>>>   section 6.1.5 in [2].
>>>
>>>   Handover home keygen token is a mobility option.  It is 
>>
>>sent by CN in
>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>   [Page 20]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>        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        
>>
>>           :
>>
>>>       :                                                    
>>
>>           :
>>
>>>       |                                                    
>>
>>           |
>>
>>>       
>>
>>>      8-bit identifier of the type of this mobility option. 
>>
>> Its value
>>
>>>      is TBD.
>>>
>>>   Option Length
>>>      This field contains the Handover home keygen token 
>>
>>generated by
>>
>>>      encrypted with the proxy mobile agent's public key.  
>>
>>The length of
>>
>>>   between two proxy mobile agents.  In the case of route 
>>
>>optimization
>>
>>>   messages, a malicious node may send such signaling 
>>
>>messages to proxy
>>
>>>   In addition, when proxy mobile agent sends data packets 
>>
>>through the
>>
>>>   bi-directional tunnel between two proxy mobile agents, 
>>
>>corresponding
>>
>>>   PMA SHOULD examine the data packets to make sure there 
>>
>>is a Binding
>>
>>>   Route optimization signaling between PMA of MN and CN 
>>
>>specified in
>>
>>>   this document is based on [5] and use return routability 
>>
>>with better
>>
>>>   security properties than the return routability of the 
>>
>>base protocol
>>
>>>
>>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>   [Page 21]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>   [2].
>>>
>>>   [1]  Bradner, S., "Key words for use in RFCs to Indicate 
>>
>>Requirement
>>
>>>        draft-ietf-mipshop-cga-cba-03 (work in progress), 
>>
>>February 2007.
>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>   [Page 22]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>   Andy Huang
>>>   Huawei Technologies
>>>   No.91 BaiXia Rd.
>>>   Nanjing, Jiangsu  210001
>>>   China
>>>
>>>   Phone: +86-25-84565457
>>>   Email: [email-masked]
>>>
>>>
>>>   Wenson Wu
>>>   Huawei Technologies
>>>   No.91 BaiXia Rd.
>>>   Nanjing, Jiangsu  210001
>>>   China
>>>
>>>   Phone: +86-25-84565459
>>>Qin, et al.              Expires August 29, 2007            
>>
>>   [Page 23]
>>
>>>> 
>>>Internet-Draft          PMIPv6 Route Optimization          
>>
>>February 2007
>>
>>>
>>>Full Copyright Statement
>>>
>>>   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
>>>
>>>   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
>>
>>>   attempt made to obtain a general license or permission 
>>
>>for the use of
>>
>>>   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
>>
>>>   rights that may cover technology that may be required to 
>>
>>implement
>>
>>>Qin, et al.              Expires August 29, 2007            
>>
>>   [Page 24]
>>
>>>
>>>
>>>

-- 
Jun Lei
PhD Student

Address: