Internet DRAFT - draft-ma-netext-pmip-handover
draft-ma-netext-pmip-handover
Network Working Group Zhengming. Ma
Internet-Draft Ke. Wang
Intended status: Standards Track Fei. Zhang
Expires: July 7, 2012 SUN YAT-SEN UNIVERSITY
January 4, 2012
Network-based Inter-domain handover Support for Proxy Mobile IPv6
draft-ma-netext-pmip-handover-02.txt
Abstract
[RFC5213] prompts the Inner-domain handover of the MN in Proxy Mobile
IPv6(PMIPv6).This document describes network-based Inter-domain
handover functionality and corresponding mobility options for
PMIPv6.This document strictly abides by the three principle describes
in PMIPv6:
(a)The movement of MN is transparent to CN.
(b)MN doesn't participate in any mobility-related signaling.LMA and
MAG are responsible for managing IP mobility on behalf of the host.
(c)This document is compatible with RFC5213.
The points of this document are as follows:
(1) Concepts: The MN's Home Agent(HA) ,Home Address (HoA) and Care-of
address(CoA) is not only for user but also for the specific
session.MN initiating a session uses the address assigned by the LMA
which the MN is registered at the moment as the HoA for the
session.The user initiating a session uses the address assigned by
the LMA which the MN moves to as the CoA for the session.
(2) Binding Cache:Every local mobility anchor must maintain two
Binding Cache entries for each currently registered mobile node. One
is Inner-domain BCE,the other is Inter-domain BCE. Inner-domain BCE
maintains the binding between MN's Proxy-CoA and MN's HoA. Inter-
domain BCE maintains the bingding between CN's HoA and CN's CoA.
(3)Communication:For the user initiating a session or accepting a
session,no matter how it moves,the HoA for the session is
unchanged,the source address of the data packets is the user's own
HoA,and the destination address of the the data packets is the HoA of
CN.The local mobility anchor will check all the packets received from
the mobile access gateway.If both the source address of the data
packets is the MN's HoA recorded in Inner-domain BCE,and the CN's HoA
and CoA recorded in Inter-domain BCE are the same,the LMA will route
Ma, et al. Expires July 7, 2012 [Page 1]
Internet-Draft Abbreviated Title January 2012
the packets directly to CN as described in RFC5213.Otherwise,
according to looking up the Inter-domain BCE,LMA gets the CoA of CN.
Then ,LMA encapsulates the packets to route to CN.On receiving a
packet from a correspondent node with the destination address
matching a mobile node's home network prefix(es), the CN's LMA MUST
first check the source address and the destination address of the
data packets,if the source address of the data packets is MN's HoA
recorded in Inter-domain BCE and the destination address is CN's HoA
recorded in Inner-domain BCE ,the CN'LMA will forward the packets to
the right MAG directly as described in RFC5213.Otherwise, CN'LMA will
remove the outer header before forwarding the packet. Then,LMA looks
up the Inner-domain BCE to forward the packets to the right MAG.
(4)Updates:When MN moves to visited LMA(MN-vLMA),MN-vLMA will do
three things.
Firstly MN-vLMA will assign a MN-CoA for MN and build up the Inner-
domain BCE for MN. Secondly,MN-vLMA will sends message to MN-hLMA to
get the HoA of CN .Then,MN-vLMA builds up the binding between CN-HoA
and CN-HoA in the Inter-domain BCE.Thirdly, MN-vLMA sends message to
CN-LMA wiht the MN-CoA and MN-HoA included in the message to help CN-
LMA updating the Inter-domain BCE for MN.
Compared with "draft-ma-netext-pmip-handover-00.txt", this document
is compatible with RFC5213 and the LMA described in this document
should decide if it is necessary to encapsulate the packets.In other
word,if MN and CN are both in their home domain,they will communicate
just as the way described in RFC5213 and otherwise they will
communicate in the way described in this document.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on July 7, 2012.
Copyright Notice
Ma, et al. Expires July 7, 2012 [Page 2]
Internet-Draft Abbreviated Title January 2012
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. The assumptions on the PMIPv6 domain . . . . . . . . . . . . . 5
4. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 6
4.1. Home address configuration . . . . . . . . . . . . . . . . 6
4.2. Binding Cache Entry Data in LMA . . . . . . . . . . . . . 7
4.3. Forwarding Considerations . . . . . . . . . . . . . . . . 7
4.3.1. Forwarding Packets Sent by the Mobile Node . . . . . . 7
4.3.2. Forwarding Packets to the Mobile Node: . . . . . . . . 7
5. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 8
6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Initial Binding Registration and Forwarding
Considerations . . . . . . . . . . . . . . . . . . . . . . 9
6.2. MN Performs Inter-domain handover . . . . . . . . . . . . 11
6.2.1. Inter-domain handover operation . . . . . . . . . . . 11
6.2.2. Forwarding Consideratons . . . . . . . . . . . . . . . 13
6.3. CN Performs Inter-domain handover . . . . . . . . . . . . 15
6.3.1. Inter-domain handover operation . . . . . . . . . . . 15
6.3.2. Forwarding Consideratons . . . . . . . . . . . . . . . 17
7. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. rPBU . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2. rPBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.3. pPBU . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.4. pPBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Ma, et al. Expires July 7, 2012 [Page 3]
Internet-Draft Abbreviated Title January 2012
1. Introduction
Proxy Mobile IPv6 (PMIPv6) [RFC5213] is network based mobility
management protocol which allows IP mobility session continuity for a
Mobile Node (MN) without its involvement in mobility management
signaling. In RFC5213 the inter-domain handover is not involved.This
document describes the network-based Inter-domain handover options,
and the corresponding functionality for Inter-domain handover for
PMIPv6. The Inter-domain handover takes place during MN moves from
home LMA(hLMA) to visited LMA(vLMA).
The network-based Inter-domain handover functionality described in
this specification does not depend on information provisioned to
external entities, such as the Domain Name System (DNS) or the
Authentication,Authorization and Accounting (AAA) infrastructure.
The trust relationship and coordination management between LMAs
within a PMIPv6 domain is deployment specific and will be described
in this specification.
2. Requirements and Terminology
2.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].
2.2. Terminology
In addition to the terminology defined in [RFC5213], the following
terminology is also used:
hLMA
Home Local Mobility Anchor is the first LMA the MN registered and is
the home agent for the mobile node in a Proxy Mobile IPv6 domain. It
is the topological anchor point for the mobile node's home network
prefix(es) and is the entity that manages the mobile node's binding
state. The local mobility anchor has the functional capabilities of
a home agent as defined in Mobile IPv6 base specification [RFC3775]
with the additional capabilities required for supporting Proxy Mobile
IPv6 protocol as defined in this specification.
vLMA
The vLMA is the LMA the MN visited.
Ma, et al. Expires July 7, 2012 [Page 4]
Internet-Draft Abbreviated Title January 2012
rPBU
A request message sent by a mobile access gateway to a mobile node's
local mobility anchor for establishing a binding between the mobile
node's home network prefix(es) assigned to a given interface of a
mobile node and its current care-of address (Proxy-CoA).
rPBA
A reply message sent by a local mobility anchor in response to a
Proxy Binding Update message that it received from a mobile access
gateway.
pPBU
A request message sent from a LMA to another LMA. There are two
kinds of message formats:a message sent from vLMA to hLMA and a
message sent from vLMA to CN's LMA.
pPBA
A reply message sent from a LMA to another LMA. There are two kinds
of message formats:a message sent from hLMA to vLMA and a message
sent from CN's LMA to vLMA.
Home AAA (hAAA):
An Authentication, Authorization, and Accounting (AAA) server located
in MN's home network. In scope of this document the hAAA corresponds
to a RADIUS server that includes the role of the PMIPv6 Policy Store.
Visited AAA (vAAA):
An Authentication, Authorization, and Accounting (AAA) server located
in MN's visited network. In this document the vAAA is the AAA server
that acts as a RADIUS Proxy when the MN moves or attaches through the
Visited network. The VAAA receives an authentication (or accounting)
request from an AAA client such as a NAS, forwards the request to the
hAAA server, receives the reply from the hAAA, and sends that reply
back to the AAA client potentially adding changes to reflect local
administrative policy.
3. The assumptions on the PMIPv6 domain
They are discussed here as they have an impact on PMIPv6 deployment.
Home AAA server records the user's static and dynamic information,and
Ma, et al. Expires July 7, 2012 [Page 5]
Internet-Draft Abbreviated Title January 2012
the dynamic information includes the information of LMA which the MN
is registered right now.
The MN's Home Address (HoA) and Care-of address(CoA) is not only for
user but also for the specific session.
MN initiating a session uses the address assigned by the LMA which
the MN is registered as the HoA for the session.The user initiating a
session uses the address assigned by the LMA which the MN moves to as
the CoA for the session.
CN accepting a session uses the address assigned by the LMA which the
CN is registered as the HoA for the session.CN accepting a session
uses the address assigned by the LMA which the CN moves to as the CoA
for the session.
For the user initiating a session or accepting a session,no matter
how it moves,the HoA for the session is unchanged,while the CoA for
the session is changing.Then, the source address of the data packets
sent by a user initiating a session or accepting a session is the
user's own HoA,and the destination address of the the data packets is
the HoA of the other end of the session.
The network-based Inter-domain handover Management not only ensures
the continuity in the session but also ensures that the MN will not
detect any change with respect to CN.
This specification diverses the PBU/PBA message into two kinds of
message formate: pPBU/pPBA message between LMAs ,rPBU/rPBA message
between LMA and MAG.
4. Local Mobility Anchor Operation
The local mobility anchor MUST support the home agent function as
defined in [RFC3775] and the extensions defined in this
specification. A home agent with these modifications and enhanced
capabilities for supporting the Proxy Mobile IPv6 protocol is
referred to as a local mobility anchor.This section describes the
operational details of the local mobility anchor.
4.1. Home address configuration
LMA not only assignes the network prefix of the home address for the
new users , but also configures the home address for the new users.So
that LMA can performs mobility management on behalf of a mobile node.
Ma, et al. Expires July 7, 2012 [Page 6]
Internet-Draft Abbreviated Title January 2012
4.2. Binding Cache Entry Data in LMA
Every local mobility anchor MUST maintain two Binding Cache entries
for each currently registered mobile node. One is Inner-domain
BCE,the other is Inter-domain BCE. Inner-domain BCE maintains the
binding between MN's Proxy-CoA and MN's HoA. Inter-domain BCE
maintains the bingding between CN's HoA and CN's CoA.
4.3. Forwarding Considerations
LMA should intercepts the packets sent to the Mobile Node's Home
Network:When the local mobility anchor is serving a mobile node, it
MUST be able to receive packets that are sent to the mobile node's
home network. In order for it to receive those packets, it MUST
advertise a connected route in to the Routing Infrastructure for the
mobile node's home network prefix(es) or for an aggregated prefix
with a larger scope. This essentially enables IPv6 routers in that
network to detect the local mobility anchor as the last-hop router
for the mobile node's home network prefix(es).
4.3.1. Forwarding Packets Sent by the Mobile Node
The local mobility anchor will check all the packets received from
the mobile access gateway.If both the source address of the data
packets is the MN's HoA recorded in Inner-domain BCE,and the CN's HoA
and CoA recorded in Inter-domain BCE are the same,the LMA will route
the packets directly to CN as described in RFC5213.Otherwise,
according to looking up the Inter-domain BCE,LMA gets the CoA of CN.
Then ,LMA encapsulates the packets to route to CN. The format of the
tunneled packet is shown below:
IPv6 header (src= LMAA, dst= CN's CoA) /* Tunnel Header */
IPv6 header (src= MN's HoA, dst= CN's HoA ) /* Packet Header */
Upper layer protocols /* Packet Content*/
4.3.2. Forwarding Packets to the Mobile Node:
On receiving a packet from a correspondent node with the destination
address matching a mobile node's home network prefix(es), the LMA
MUST first check the source address and the destination address of
the data packets,if the source address of the data packets is CN's
HoA recorded in Inter-domain BCE and the destination address is MN's
HoA recorded in Inner-domain BCE ,the LMA will forward the packets to
the right MAG directly as described in RFC5213.Otherwise, LMA will
remove the outer header before forwarding the packet. Then,LMA looks
up the Inner-domain BCE to forward the packets to the right MAG. The
Ma, et al. Expires July 7, 2012 [Page 7]
Internet-Draft Abbreviated Title January 2012
format of the tunneled packet is shown below:
IPv6 header (src= LMAA, dst= MN's Proxy CoA) /* Tunnel Header */
IPv6 header (src= CN's HoA, dst= MN's HoA ) /* Packet Header */
Upper layer protocols /* Packet Content*/
5. Mobile Access Gateway Operation
RFC5213 introduces a new functional entity, the mobile access gateway
(MAG).The mobile access gateway is the entity that is responsible for
detecting the mobile node's movements to and from the access link and
sending the Proxy Binding Update messages to the local mobility
anchor. In essence, the mobile access gateway performs mobility
management on behalf of a mobile node.
Every mobile access gateway MUST maintain a Binding Update List.Each
entry in the Binding Update List represents a mobile node's mobility
binding with its local mobility anchor. The Binding Update List is a
conceptual data structure.
For supporting this specification, the conceptual Binding Update List
entry data structure needs be extended as follows:
(a)After detecting a new mobile node on its access link, the mobile
access gateway MUST identify the mobile node and acquire its MN-
Identifier. If it determines that the network-based mobility
management service needs to be offered to the mobile node, it MUST
send a Proxy Binding Update message to the local mobility anchor.
(b)If the MAG detectes the MN's registration is initial binding
registration , the MAG will maintain a binding between MN's HoA and
hLMA when it recieves the rPBA message.
(c)If the MAG detectes the MN is performing a inter-domain handover ,
the MAG will maintain a binding between MN's HoA ,vLMA and CoA when
it recieves the rPBA message from vLMA. The CoA which is included in
rPBA message is the address vLMA assigns for MN.
6. Protocol Operation
In order to improve the performance during inter-handover (when
operations such as attachment to a new LMA and signaling between LMAs
are involved), the PFMIPv6 protocol in this document specifies new
message forms between the MN's hLMA and MN's vLMA and new message
Ma, et al. Expires July 7, 2012 [Page 8]
Internet-Draft Abbreviated Title January 2012
forms between the MN's vLMA and CN's LMA. In this specification take
the communication between MN and CN as a example. Both MN and CN are
in PMIPv6 domain.
6.1. Initial Binding Registration and Forwarding Considerations
Both MN and CN are in PMIPv6 domain.The related signaling of Initial
Binding Registration is described in RFC5213. Both MN and CN has
registered in its hLMA ,and both gets its home address (MN-HoA and
CN-HoA).The reference network is illustrated in Figure 1.
+---------+ +----------+
| MN-hLMA |---------| CN-hLMA |
+---------+ +----------+
| |
| |
+---------+ +----------+
| MN-MAG | | CN-MAG |
+---------+ +----------+
| |
| |
+---------+ +----------+
| MN | | CN |
+---------+ +----------+
Figure 1:Reference network for Initial Binding Registration and
Forwarding Considerations
Forwarding Considerations:
(a) Packets from MN to CN:
(1).The source address is MN-HoA, and the destination address is CN-
HoA.
(2).The packets are forwarded from MN to MN-MAG through Link-layer.
(3).The packets are forwarded form MN-MAG to MN-hLMA through tunnel,
the source address of the tunnel is MN-MAG's IP address (MN-Proxy-
CoA), and the destination address of the tunnel is MN-hLMA's address
(MN-hLMAA).
(4).MN-hLMA decapsulates the packets and check both the source
address and the destination address of the data packets.If both the
source address of the data packets is the MN's HoA recorded in Inner-
domain BCE,and the CN's HoA and CoA recorded in Inter-domain BCE are
Ma, et al. Expires July 7, 2012 [Page 9]
Internet-Draft Abbreviated Title January 2012
the same,the LMA will route the packets directly to CN as described
in RFC5213.
(5)The packets are intercepted by CN-hLMA.CN-hLMA MUST first check
the source address and the destination address of the data packets,if
the source address of the data packets is MN's HoA recorded in Inter-
domain BCE and the destination address is CN's HoA recorded in Inner-
domain BCE ,the CN-hLMA forwards the packets to the right MAG
directly as described in RFC5213.CN-hLMA forwards them to CN-MAG
through tunnel, the source address of the tunnel is CN-hLMA's address
(CN-hLMAA), and the destination address of the tunnel is CN-MAG's
address (CN-Proxy-CoA).
(6)CN-MAG decapsulates the packets and forwards them to CN through
Link-layer.
(b) Packets from CN to MN:
(1).The source address is CN-HoA , and the destination address is MN-
HoA .
(2).The packets are forwarded from CN to CN-MAG through Link-layer.
(3).The packets are forwarded form CN-MAG to CN-hLMA through tunnel,
the source address of the tunnel is CN-Proxy-CoA and the destination
address of the tunnel is CN-hLMAA.
(4).CN-hLMA decapsulates the packets and check both the source
address and the destination address of the data packets.If both the
source address of the data packets is the CN's HoA recorded in Inner-
domain BCE,and the MN's HoA and CoA recorded in Inter-domain BCE are
the same,the LMA will route the packets directly to CN as described
in RFC5213.
(5). The packets are intercepted by MN-hLMA.The packets are
intercepted by MN-hLMA.MN-hLMA MUST first check the source address
and the destination address of the data packets,if the source address
of the data packets is CN's HoA recorded in Inter-domain BCE and the
destination address is MN's HoA recorded in Inner-domain BCE ,the MN-
hLMA forwards the packets to the right MAG directly as described in
RFC5213.
(6).MN-MAG decapsulates the packets and forwards them to MN through
Link-layer.
Ma, et al. Expires July 7, 2012 [Page 10]
Internet-Draft Abbreviated Title January 2012
6.2. MN Performs Inter-domain handover
On the basis of situation described in 6.1,MN roams to MN-vLMA domain
and CN is still in its home domain.The reference network is
illustrated in Figure 2.
+------------------------------------------+
| |
+---------+ +---------+ +----------+
| MN-vLMA |-----| MN-hLMA | | CN-hLMA |
+---------+ +---------+ +----------+
| |
| |
+---------+ +----------+
| MN-MAG2 | | CN-MAG |
+---------+ +----------+
| |
| |
+---------+ +----------+
| MN | | CN |
+---------+ +----------+
Figure 2:MN roams to MN- vLMA domain
6.2.1. Inter-domain handover operation
In RFC5213 the inter-domain handover is not involved.This document
describes the network-based Inter-domain handover options, and the
corresponding functionality for Inter-domain handover for
PMIPv6.Since the MN is not involved in IP mobility signaling in
PMIPv6, the sequence of events illustrating the MN inter-domain
handover are shown in Figure 3.
Ma, et al. Expires July 7, 2012 [Page 11]
Internet-Draft Abbreviated Title January 2012
+-------+ RADIUS +-------+
|MN-hAAA|<---------->|MN-vAAA|
+-------+ +-------+
|RADIUS
|
+--+ +------+ +-------+ +-------+ +-------+ +-------+
|MN| |MN-MAG| |MN-hLMA| |MN-MAG2| |MN-vLMA| |CN-hLMA|
+--+ +------+ +-------+ +-------+ +-------+ +-------+
| | | | | |
| |DeReg PBU | | | |
| |------- ->| | | |
| | rPBA | | | |
| |<---------| | | |
| | RS | | | |
|------------------------>| | |
| | | | | |
| | | | rPBU | |
| | | |----------> |
| | | | rPBA | |
| | | <----------| |
| | | | pPBU | |
| | <------------------| |
| | | | pPBA | |
| | |----------------->| |
| | | | | pPBU| |
| | | | |--------->
| | | | | pPBA |
| | RA | | |<--------|
|<------------------------| | |
| | | | | |
Figure 3:signaling of MN inter-handover
(a)MN-MAG detects that a handover is imminent and sends the DeReg PBU
message to the MN-hLMA asking MN-hLMA to remove the binding between
MN-MAG and MN.
(b)The MN-hLMA sends back the rPBA message to MN-MAG.
(c) MN roams to MN-vLMA, and sends Router Solicit(RS) message to MN-
MAG2. The MN-HoA and CN-HoA are included in RS message.
(d) Upon receiving RS message ,MN-MAG2 sends request to download the
per MN Policy Profile from the MN-vAAA.
Ma, et al. Expires July 7, 2012 [Page 12]
Internet-Draft Abbreviated Title January 2012
(e)MN-vAAA assigns a MN-vLMA to MN -MAG2 ,and sends request to MN-
hAAA to download the per MN Policy Profile . MN-vLMA's address is
included in the request message.
(f)MN-hAAA receives the request message and sends the MN Policy
Profile to MN-vAAA ,then MN-hAAA uses MN-vLMAA to take place of MN-
hLMAA.
(g)MN-vAAA sends the Accept Message which includes both MN-hLMAA and
MN-vLMAA to MN-MAG2.
(h) MN-MAG2 sends the rPBU message to MN-vLMA. MN-HoA,CN-HoA and MN-
hLMAA are included in rPBU message .
(i) Upon receiving rPBU message, MN-vLMA firstly assigns a MN-CoA for
MN ,builds up the inner-domain BCE for MN and sends rPBA message back
to MN-MAG2 .The MN-CoA is included in rPBA message.In the Inner-
domain BCE there is a binding between MN's Proxy-CoA2 and MN's CoA.
Secondly,MN-vLMA sends pPBU message to MN-hLMA,the source address of
the pPBU message is MN-vLMAA and the destination address of the pPBU
message is MN-hLMAA. CN-HoA is included in pPBU message. Upon
receiving the pPBU message,MN-hLMA sends back pPBA message to MN-
vLMA with CN-HoA included .MN-vLMA builds up the binding between CN-
HoA and CN-HoA in the Inter-domain BCE.
Thirdly,MN-vLMA sends pPBU message to CN-hLMA, the source address of
the pPBU message is MN-CoA and the destination address of the pPBU
message is CN-HoA.The pPBU message includes the MN-CoA and MN-HoA.
This pPBU message is packaged in UDP format,and by judging the format
of the message CN-hLMA intercepts the pPBU message ,encapsulates the
message and updates the Inter-domain BCE for MN. That means in the
Inter-domain BCE there is a binding between MN-CoA and MN-HoA.
(j) After receiving rPBA message from MN-vLMA, MN-MAG2 builds up the
binding among MN-HoA ,MN-CoA and MN-vLMA. Then MN-MAG2 sends Router
Advertise (RA) message to MN. The inter-domain handover operation is
over.
6.2.2. Forwarding Consideratons
Forwarding Considerations:
(a) Packets from MN to CN:
(1).The source address is MN-HoA, and the destination address is CN-
HoA.
Ma, et al. Expires July 7, 2012 [Page 13]
Internet-Draft Abbreviated Title January 2012
(2).The packets are forwarded from MN to MN-MAG2 through Link-layer.
(3).The packets are forwarded form MN-MAG2 to MN-hLMA through tunnel,
the source address of the tunnel is MN-MAG2's IP address, and the
destination address of the tunnel is MN-vLMAA.
(4).According to check both the source address and the destination
address of the data packets.MN-vLMA detects the MN and CN are not
both in their home domain,so MN-vLMA encapsulates the packets to
route to CN. The format of the tunneled packet is shown below:
IPv6 header (src= MN-vLMAA, dst= CN's HoA) /* Tunnel Header */
IPv6 header (src= MN's HoA, dst= CN's HoA ) /* Packet Header */
Upper layer protocols /* Packet Content*/
(5).The packets are intercepted by CN-hLMA.According to check both
the source address and the destination address of the data
packets.CN-hLMA detects the MN and CN are not both in their home
domain,CN-hLMA decapsulates the packets and forwards them to CN-MAG
through tunnel, the source address of the tunnel is CN-hLMAA, and the
destination address of the tunnel is CN-Proxy-CoA .
(6).CN-MAG decapsulates the packets and forwards them to CN through
Link-layer.
(b) Packets from CN to MN:
(1).The source address is CN-HoA , and the destination address is MN-
HoA .
(2).The packets are forwarded from CN to CN-MAG through Link-layer.
(3).The packets are forwarded form CN-MAG to CN-hLMA through tunnel,
the source address of the tunnel is CN-Proxy-CoA and the destination
address of the tunnel is CN-hLMAA.
(4).According to check both the source address and the destination
address of the data packets.CN-hLMA detects the MN and CN are not
both in their home domain,so CN-hLMA encapsulates the packets to
route to MN..The format of the tunneled packet is shown below:
IPv6 header (src= CN-hLMAA, dst= MN's CoA) /* Tunnel Header */
IPv6 header (src= CN's HoA, dst= MN's HoA ) /* Packet Header */
Upper layer protocols /* Packet Content*/
Ma, et al. Expires July 7, 2012 [Page 14]
Internet-Draft Abbreviated Title January 2012
(5). The packets are intercepted by MN-vLMA.MN-vLMA decapsulates the
packets and forwards them to MN-MAG2 through tunnel, the source
address of the tunnel is MN-vLMAA, and the destination address of the
tunnel is MN-Proxy-CoA2.
(6).MN-MAG2 decapsulates the packets and forwards them to MN through
Link-layer.
6.3. CN Performs Inter-domain handover
On the basis of situation described in 6.2,CN roams to CN-vLMA domain
and MN is still in MN-vLMA domain.The reference network is
illustrated in Figure 4.
+--------------------------------------------+
| |
+---------+ +---------+ +----------+ +----------+
| MN-vLMA |---| MN-hLMA | | CN-hLMA |---| CN-vLMA |
+---------+ +---------+ +----------+ +----------+
| |
| |
+---------+ +----------+
| MN-MAG2 | | CN-MAG2 |
+---------+ +----------+
| |
| |
+---------+ +----------+
| MN | | CN |
+---------+ +----------+
Figure 4:CN roams to CN- vLMA domain
6.3.1. Inter-domain handover operation
The sequence of events illustrating the CN inter-domain handover are
shown in Figure 5.
Ma, et al. Expires July 7, 2012 [Page 15]
Internet-Draft Abbreviated Title January 2012
+-------+ RADIUS +-------+
|CN-hAAA|<---------->|CN-vAAA|
+-------+ +-------+
|RADIUS
|
+--+ +------+ +-------+ +-------+ +-------+ +-------+
|CN| |CN-MAG| |CN-hLMA| |CN-MAG2| |CN-vLMA| |MN-vLMA|
+--+ +------+ +-------+ +-------+ +-------+ +-------+
| | | | | |
| |DeReg PBU | | | |
| |------- ->| | | |
| | rPBA | | | |
| |<---------| | | |
| | RS | | | |
|------------------------>| | |
| | | | | |
| | | | | |
| | | | | |
| | | | rPBU | |
| | | |----------> |
| | | | rPBA | |
| | | <----------| |
| | | | pPBU | |
| | <------------------| |
| | | | pPBA | |
| | |----------------->| |
| | | | | pPBU| |
| | | | |--------->
| | | | | pPBA |
| | RA | | |<--------|
|<------------------------| | |
| | | | | |
Figure 5:signaling of CN inter-handover
(a)CN-MAG detects that a handover is imminent and sends the DeReg PBU
message to the CN-hLMA asking CN-hLMA to remove the binding between
CN-MAG and CN.
(b)The CN-hLMA sends back the rPBA message to CN-MAG.
Ma, et al. Expires July 7, 2012 [Page 16]
Internet-Draft Abbreviated Title January 2012
(c) CN roams to CN-vLMA, and sends RS message to CN-MAG2. The CN-HoA
and MN-HoA are included in RS message.
(d) Upon receiving RS message ,CN-MAG2 sends request to download the
per CN Policy Profile from the CN-vAAA.
(e)CN-vAAA assigns a CN-vLMA to CN -MAG2 ,and sends request to CN-
hAAA to download the per CN Policy Profile . CN-vLMA's address is
included in the request message.
(f)CN-hAAA receives the request message and sends the CN Policy
Profile to CN-vAAA ,then CN-hAAA uses CN-vLMAA to take place of CN-
hLMAA.
(g)CN-vAAA sends the Accept Message which includes both CN-hLMAA and
CN-vLMAA to CN-MAG2.
(h) CN-MAG2 sends the rPBU message to CN-vLMA. MN-HoA,CN-HoA and CN-
hLMAA are included in rPBU message .
(i) Upon receiving rPBU message, CN-vLMA firstly assigns a CN-CoA for
CN ,builds up the inner-domain BCE for CN and sends rPBA message back
to CN-MAG2 .The CN-CoA is included in rPBA message.In the Inner-
domain BCE there is a binding between CN's Proxy-CoA2 and CN's CoA.
Secondly,CN-vLMA sends pPBU message to CN-hLMA,the source address of
the pPBU message is CN-vLMAA and the destination address of the pPBU
message is CN-hLMAA. MN-HoA is included in pPBU message. Upon
receiving the pPBU message,CN-hLMA sends back pPBA message to CN-vLMA
with MN-HoA and MN-CoA included .CN-vLMA updates the inter-domain BCE
with the binding between MN-HoA and MN-CoA.
Thirdly,CN-vLMA sends pPBU message to MN-hLMA, the source address of
the pPBU message is CN-CoA and the destination address of the pPBU
message is MN-CoA.The pPBU message includes the CN-CoA and CN-HoA.
This pPBU message is packaged in UDP format,and by judging the format
of the message MN-hLMA intercepts the pPBU message ,encapsulates the
message and updates the Inter-domain BCE for CN. That means in the
Inter-domain BCE there is a binding between CN-CoA and CN-HoA.
(j) After receiving rPBA message from CN-vLMA, CN-MAG2 builds up the
binding among CN-HoA ,CN-CoA and CN-vLMA. Then CN-MAG2 sends RA
message to CN. The inter-domain handover operation is over.
6.3.2. Forwarding Consideratons
Forwarding Considerations:
Ma, et al. Expires July 7, 2012 [Page 17]
Internet-Draft Abbreviated Title January 2012
(a) Packets from MN to CN:
(1).The source address is MN-HoA, and the destination address is CN-
HoA.
(2).The packets are forwarded from MN to MN-MAG2 through Link-layer.
(3).The packets are forwarded form MN-MAG2 to MN-hLMA through tunnel,
the source address of the tunnel is MN-MAG2's IP address, and the
destination address of the tunnel is MN-vLMAA.
(4). According to check both the source address and the destination
address of the data packets.CN-hLMA detects the MN and CN are not
both in their home domain,so MN-vLMA encapsulates the packets to
route to CN. The format of the tunneled packet is shown below:
IPv6 header (src= MN-vLMAA, dst= CN's CoA) /* Tunnel Header */
IPv6 header (src= MN's HoA, dst= CN's HoA ) /* Packet Header */
Upper layer protocols /* Packet Content*/
(5).The packets are intercepted by CN-vLMA. According to check both
the source address and the destination address of the data
packets.CN-hLMA detects the MN and CN are not both in their home
domain,so CN-vLMA decapsulates the packets and forwards them to CN-
MAG2 through tunnel, the source address of the tunnel is CN-vLMAA,
and the destination address of the tunnel is CN-Proxy-CoA2 .
(6).CN-MAG2 decapsulates the packets and forwards them to CN through
Link-layer.
(b) Packets from CN to MN:
(1).The source address is CN-HoA , and the destination address is MN-
HoA .
(2).The packets are forwarded from CN to CN-MAG2 through Link-layer.
(3).The packets are forwarded form CN-MAG2 to CN-vLMA through tunnel,
the source address of the tunnel is CN-Proxy-CoA2 and the destination
address of the tunnel is CN-vLMAA.
(4). According to check both the source address and the destination
address of the data packets.CN-hLMA detects the MN and CN are not
both in their home domain,so CN-vLMA encapsulates the packets to
route to MN. The format of the tunneled packet is shown below:
Ma, et al. Expires July 7, 2012 [Page 18]
Internet-Draft Abbreviated Title January 2012
IPv6 header (src= CN-vLMAA, dst= MN's CoA) /* Tunnel Header */
IPv6 header (src= CN's HoA, dst= MN's HoA ) /* Packet Header */
Upper layer protocols /* Packet Content*/
(5). The packets are intercepted by MN-vLMA. According to check
both the source address and the destination address of the data
packets.CN-hLMA detects the MN and CN are not both in their home
domain,so MN-vLMA decapsulates the packets and forwards them to MN-
MAG2 through tunnel, the source address of the tunnel is MN-vLMAA,
and the destination address of the tunnel is MN-Proxy-CoA2.
(6).MN-MAG2 decapsulates the packets and forwards them to MN through
Link-layer.
7. Message Formats
This section defines extensions to the Proxy Mobile IPv6 [RFC5213]
protocol messages.
7.1. rPBU
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|D| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-Identifier |
| MN-hLMAA |
| CN-HoA |
| MN-HoA |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6:rPBU
A Binding Update message that is sent by a mobile access gateway to a
local mobility anchor is referred to as the "rPBU" message.A new flag
(D) is included in the rPBU message. The rest of the Binding Update
message format remains the same as defined in [RFC5213] and with the
additional (R) and (M) flags, as specified in [RFC3963] and
Ma, et al. Expires July 7, 2012 [Page 19]
Internet-Draft Abbreviated Title January 2012
[RFC4140], respectively.
Distinguish Flag (D)
A new flag (D) is included in the Binding Update message to indicate
to the local mobility anchor that the Binding Update message is a
proxy registration sent by a mobile access gateway to a local
mobility anchor. The flag MUST be set to the value of 1 .
The rPBU message sent by a mobile access gateway to a local mobility
anchorcontains MN-Identifer , MN-hLMAA, MN-HoA and CN-HoA.
7.2. rPBA
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|D|Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN's IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7:rPBA
A Binding Acknowledgement message that is sent by a local mobility
anchor to a mobile access gateway is referred to as the "rPBA"
message. A new flag (D) is included in the Binding Acknowledgement
message. The rest of the Binding Acknowledgement message format
remains the same as defined in [RFC5213] and with the additional (R)
flag as specified in [RFC3963].
Distinguish Registration Flag (D)
A new flag (D) is included in the Binding Acknowledgement message to
indicate that the local mobility anchor processed the corresponding
Proxy Binding Update message as rPBU message. The flag is set to a
value of 1 . The rPBA message sent by a local mobility anchor to a
mobile access gateway contains MN's IP address assigned by the local
mobility anchor .
Ma, et al. Expires July 7, 2012 [Page 20]
Internet-Draft Abbreviated Title January 2012
7.3. pPBU
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|D| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8:pPBU
A Binding Update message that is sent by a local mobility anchor to a
local mobility anchor is referred to as the "pPBU" message.A new flag
(D) and a new flag (M) are included in the pPBU message. The rest of
the Binding Update message format remains the same as defined in
[RFC5213] and with the additional (R) and (M) flags, as specified in
[RFC3963] and [RFC4140], respectively.
Distinguish Flag (D)
A new flag (D) is included in the Binding Update message to indicate
to the local mobility anchor that the Binding Update message is a
proxy registration sent by a local mobility anchor to a local
mobility anchor. The flag MUST be set to the value of 2 or 3.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|D| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-HoA |
| CN-HoA |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9:pPBU sent by a visit LMA to the home LMA
A new flag (D) is included in the Binding Update message to indicate
to the local mobility anchor that the Binding Update message is a PBU
Ma, et al. Expires July 7, 2012 [Page 21]
Internet-Draft Abbreviated Title January 2012
message sent by a visit local mobility anchor to the home local
mobility anchor. The flag MUST be set to the value of 2. This pPBU
message sent by a visit local mobility anchor to the home local
mobility anchor contains MN-HoA and CN-HoA.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|D| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-HoA |
| MN-CoA |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10:pPBU sent by MN's LMA to CN's LMA
A new flag (D) is included in the Binding Update message to indicate
to the local mobility anchor that the Binding Update message is a PBU
message sent by MN's local mobility anchor to CN's local mobility
anchor . The flag MUST be set to the value of 3.This pPBU message
sent by MN's local mobility anchor to CN's local mobility anchor
contains MN-HoA and MN-HoA.
7.4. pPBA
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|D|Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11:pPBA
A Binding Acknowledgement message that is sent by a local mobility
anchor to a local mobility anchor is referred to as the "pPBA"
Ma, et al. Expires July 7, 2012 [Page 22]
Internet-Draft Abbreviated Title January 2012
message. A new flag (D) and a new flag (M) are included in the
Binding Acknowledgement message. The rest of the Binding
Acknowledgement message format remains the same as defined in
[RFC5213] and with the additional (R) flag as specified in [RFC3963].
Distinguish Registration Flag (D)
A new flag (D) is included in the Binding Acknowledgement message to
indicate that the local mobility anchor processed the corresponding
Proxy Binding Update message as pPBU message. The flag is set to a
value of 2 or 3.
A new flag (D) is included in the Binding Acknowledgement message to
indicate that the local mobility anchor processed the corresponding
Proxy Binding Update message as pPBU message sent by a visit local
mobility anchor to the home local mobility anchor. The flag is set
to a value of 2 .The options of the message contains the CN-CoA.
A new flag (D) is included in the Binding Acknowledgement message to
indicate that the local mobility anchor processed the corresponding
Proxy Binding Update message as pPBU message sent by MN's local
mobility anchor to CN's local mobility anchor. The flag is set to a
value of 3 .
8. Security Considerations
The potential security threats against any network-based mobility
management protocol are described in [RFC4832]. This section
explains how Proxy Mobile IPv6 protocol defends itself against those
threats.
Proxy Mobile IPv6 protocol recommends the signaling messages, Proxy
Binding Update and Proxy Binding Acknowledgement, exchanged between
the mobile access gateway and the local mobility anchor or between a
local mobility anchor and a local mobility anchorto be protected
using IPsec using the established security associationbetween them.
This essentially eliminates the threats related to the impersonation
of the mobile access gateway or the local mobility anchor.
This specification allows a mobile access gateway to send binding
registration messages on behalf of a mobile node. If proper
authorization checks are not in place, a malicious node may be able
to hijack a mobile node's mobility session or may carry out a denial-
of-service attack. To prevent this attack, this specification
requires the local mobility anchor to allow only authorized mobile
access gateways that are part of that Proxy Mobile IPv6 domain to
send Proxy Binding Update messages on behalf of a mobile node.
Ma, et al. Expires July 7, 2012 [Page 23]
Internet-Draft Abbreviated Title January 2012
To eliminate the threats on the interface between the mobile access
gateway and the mobile node, this specification requires an
established trust between the mobile access gateway and the mobile
node and to authenticate and authorize the mobile node before it is
allowed to access the network. Further, the established
authentication mechanisms enabled on that access link will ensure
that there is a secure binding between the mobile node's identity and
its link-layer address. The mobile access gateway will definitively
identify the mobile node from the packets that it receives on that
access link.
To address the threat related to a compromised mobile access gateway,
the local mobility anchor, before accepting a Proxy Binding Update
message for a given mobile node, may ensure that the mobile node is
attached to the mobile access gateway that sent the Proxy Binding
Update message. This may be accomplished by contacting a trusted
entity, which is able to track the mobile node!_s current point of
attachment. However, the specific details of the actual mechanisms
for achieving this is outside the scope of this document.
9. IANA Considerations
This document defines six new Mobility Header options, the
HomeNetwork Prefix Option, Handoff Indicator Option, Access
Technology Type Option, Mobile Node Link-layer Identifier Option,
Link-local Address Option, and Timestamp Option. The Type value for
these options has been assigned from the same numbering space as
allocated for the other mobility options,as defined in [RFC3775].
The Handoff Indicator Option introduces a new Handoff Indicator (HI)
numbering space, where the values from 0 to 5 have been reserved by
this document. Approval of new Handoff Indicator type values are to
be made through IANA Expert Review.
The Access Technology Type Option introduces a new Access Technology
type (ATT) numbering space, where the values from 0 to 5 have been
reserved by this document. Approval of new Access Technology type
values are to be made through IANA Expert Review.
This document also defines new Binding Acknowledgement status values.
The status values MUST be assigned from the same number space used
for Binding Acknowledgement status values,as defined in [RFC3775].
The allocated values for each of thesestatus values must be greater
than 128.
This document creates a new registry for the flags in the Binding
Ma, et al. Expires July 7, 2012 [Page 24]
Internet-Draft Abbreviated Title January 2012
Update message called the "Distinguish Flag".
The following flags are reserved:
(A) 0x8000 [RFC3775]
(H)0x4000 [RFC3775]
(L)0x2000 [RFC3775]
(K) 0x1000 [RFC3775]
(M) 0x0800 [RFC4140]
(R) 0x0400 [RFC3963]
(P) 0x0200[RFC5213]
This document reserves a new flag (D) as follows:
(D) 0x0100
The rest of the values in the 16-bit field are reserved. New values
can be assigned by Standards Action or IESG approval.
This document also creates a new registry for the flags in the
Binding Acknowledgment message called the "Distinguish Flag". The
following values are reserved.
(K) 0x80 [RFC3775]
(R) 0x40 [RFC3963]
(P) 0x20 [RFC5213]
This document reserves a new flag (D) as follows:
(D) 0x10
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
Ma, et al. Expires July 7, 2012 [Page 25]
Internet-Draft Abbreviated Title January 2012
IPv6 Specification", RFC 2473, December 1998.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, November 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
10.2. Informative References
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
Ma, et al. Expires July 7, 2012 [Page 26]
Internet-Draft Abbreviated Title January 2012
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L.
Bellier, "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)", RFC 4140, August 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney,
"Chargeable User Identity", RFC 4372, January 2006.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
[RFC4830] Kempf, J., "Problem Statement for Network-Based Localized
Mobility Management (NETLMM)", RFC 4830, April 2007.
[RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility
Management (NETLMM)", RFC 4831, April 2007.
Authors' Addresses
Zhengming Ma
SUN YAT-SEN UNIVERSITY
Department of Electronics and Engineering,daxuecheng,313
Zhongshan University,Guangzhou, 510006
P.R. China
Email: issmzm@mail.sysu.edu.cn
Ma, et al. Expires July 7, 2012 [Page 27]
Internet-Draft Abbreviated Title January 2012
Ke Wang
SUN YAT-SEN UNIVERSITY
Department of Electronics and Engineering,daxuecheng,313
Zhongshan University,Guangzhou, 510006
P.R. China
Email: wang923zheng@sina.com
Fei Zhang
SUN YAT-SEN UNIVERSITY
Department of Electronics and Engineering,daxuecheng,313
Zhongshan University,Guangzhou, 510006
P.R. China
Email: zsu05zhangfei@163.com
Ma, et al. Expires July 7, 2012 [Page 28]
