RE: [netlmm] Welcome your comments on draft-qin-mipshop-pmipro-00.txt
qinxia <alice.Q@huawei.com> Wed, 18 April 2007 03:14 UTC
Return-path: <netlmm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He0dE-0005Ud-RE; Tue, 17 Apr 2007 23:14:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He0dC-0005UX-V0 for netlmm@ietf.org; Tue, 17 Apr 2007 23:14:54 -0400
Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He0d8-0005wv-Us for netlmm@ietf.org; Tue, 17 Apr 2007 23:14:54 -0400
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGO00530BNEK2@szxga03-in.huawei.com> for netlmm@ietf.org; Wed, 18 Apr 2007 11:14:02 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGO00J5UBN1EO@szxga03-in.huawei.com> for netlmm@ietf.org; Wed, 18 Apr 2007 11:14:02 +0800 (CST)
Received: from q52443 ([10.164.5.117]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGO007OEBMYH5@szxml04-in.huawei.com> for netlmm@ietf.org; Wed, 18 Apr 2007 11:13:49 +0800 (CST)
Date: Wed, 18 Apr 2007 11:13:46 +0800
From: qinxia <alice.Q@huawei.com>
Subject: RE: [netlmm] Welcome your comments on draft-qin-mipshop-pmipro-00.txt
In-reply-to: <462488F6.3010203@informatik.uni-goettingen.de>
To: 'Jun Lei' <lei@informatik.uni-goettingen.de>
Message-id: <003301c78167$93d62cd0$7505a40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
Thread-index: AceAzOUtGo9F8EuRTWKdjec22D6BrQAk+qxA
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de9dabb9a3ceb021f26761a300a4624c
Cc: netlmm@ietf.org
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
Errors-To: netlmm-bounces@ietf.org
Hello Lei,
Thanks for your comments! Please kindly see inlines.
Best wishes
Alice
> -----Original Message-----
> From: Jun Lei [mailto:lei@informatik.uni-goettingen.de]
> Sent: Tuesday, April 17, 2007 4:45 PM
> To: qinxia
> Cc: netlmm@ietf.org
> Subject: Re: [netlmm] Welcome your comments on
> draft-qin-mipshop-pmipro-00.txt
>
> 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.
[qx] yes, as I said on presentation.
>
> 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.
>
[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.
> 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?
[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.
>
> 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.
>
[qx] ok, I will fix it in the revision. Thanks.
> 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?
>
[qx] if PMA has no permanent home keygen token, or the token is needed to be updated,
then these tokens should be generated.
> 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.
[qx] inter-domain? I did not find this word in this draft, could you point it out?
Thanks.
>
> 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: Alice.Q@huawei.com
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 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: hpanda@huawei.com
> >
> >
> > Wenson Wu
> > Huawei Technologies
> > No.91 BaiXia Rd.
> > Nanjing, Jiangsu 210001
> > China
> >
> > Phone: +86-25-84565459
> > Email: sunseawq@huawei.com
> >
> >
> > Behcet Sarikaya
> > Huawei Technologies
> > 1700 Alma Dr. Suite 100
> > Plano, TX 75075
> >
> > Email: sarikaya@ieee.org
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 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
> > ietf-ipr@ietf.org.
> >
> >
> > 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
> > netlmm@ietf.org
> > 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: lei@informatik.uni-goettingen.de
>
_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www1.ietf.org/mailman/listinfo/netlmm
- [netlmm] Draft Agenda for NETLMM at IETF68 Narayanan, Vidya
- Re: [netlmm] Draft Agenda for NETLMM at IETF68 Behcet Sarikaya
- Re: [netlmm] Draft Agenda for NETLMM at IETF68 Vijay Devarapalli
- Re: [netlmm] Draft Agenda for NETLMM at IETF68 Myung-Ki Shin
- RE: [netlmm] Draft Agenda for NETLMM at IETF68 Narayanan, Vidya
- Re: [netlmm] Draft Agenda for NETLMM at IETF68 Julien Laganier
- Re: [netlmm] Draft Agenda for NETLMM at IETF68 Behcet Sarikaya
- RE: [netlmm] Draft Agenda for NETLMM at IETF68 Narayanan, Vidya
- Re: [netlmm] Draft Agenda for NETLMM at IETF68 Vijay Devarapalli
- [netlmm] Welcome your comments on draft-qin-mipsh… qinxia
- Re: Slot for SDO Operationals (was: [netlmm] Draf… Alexandru Petrescu
- RE: Slot for SDO Operationals (was: [netlmm] Draf… Narayanan, Vidya
- [netlmm] Re: [net] Draft Agenda for NETLMM at IET… Katsutoshi Nishida
- [netlmm] RE: [net] Draft Agenda for NETLMM at IET… Narayanan, Vidya
- [netlmm] Re: [net] Draft Agenda for NETLMM at IET… Katsutoshi Nishida
- Re: [netlmm] Welcome your comments on draft-qin-m… Jun Lei
- RE: [netlmm] Welcome your comments on draft-qin-m… qinxia
- Re: [netlmm] Welcome your comments on draft-qin-m… Jun Lei