IETF NETLMM Working Group Anand Bedekar
Internet Draft Ajoy Singh
Vinod Kumar
Suresh Kalyanasundaram
Motorola
draft-singh-netlmm-protocol-02.txt
Expires: September 05, 2007 March 05, 2007
A Protocol for Network-based Localized Mobility Management
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document suggests a localized mobility solution controlled
by the network within a local mobility domain. The proposed
solution is based on Proxy Mobile IPv6 (PMIP) technique and
employs a PMIP client that generates a Proxy Binding Update
message. The solution allows for a clean separation between the
bearer and signaling paths, and reuse of MIPv6 home agent as the
local mobility anchor. The security association between the
Singh et. al Expires September 5, 2007 [Page 1]
Internet-Draft A Protocol for NETLMM March 5, 2007
network elements for executing the local mobility is also
discussed.
TABLE OF CONTENTS
1.0 INTRODUCTION...............................................3
2.0 TERMINOLOGY................................................3
3.0 BRIEF DESCRIPTION OF SOLUTION..............................5
4.0 PROTOCOL DETAILS...........................................7
4.1 INITIAL ATTACHMENT........................................7
4.2 INTRA-LMD MOBILITY........................................9
4.3 SECURITY ASSOCIATION BETWEEN PMIP CLIENT AND LMA..........11
4.4 INTER-LMA MOBILITY.......................................12
4.5 RELOCATION OF PMIP CLIENT.................................12
4.6 HANDLING OF MIPv6 CAPABLE MNs IN THE LMD..................12
4.7 PMIP CLIENT CONSIDERATIONS................................13
4.8 LMA CONSIDERATIONS........................................13
4.9 MAG - PMIP CLIENT INTERACTION.............................14
4.9.1 TRIGGER MESSAGE.........................................14
4.9.2 NOTIFICATION MESSAGE....................................15
4.9.3. MAG-PMIP client Transport..............................16
4.9.4. MAG-PMIP client Security...............................17
5.0 IANA CONSIDERATIONS........................................17
6.0 SECURITY CONSIDERATIONS....................................17
7.0 NORMATIVE REFERENCES.......................................18
8.0 INFORMATIVE REFERENCES.....................................18
9.0 AUTHORS' ADDRESSES.........................................19
APPENDIX A. pHoA ASSIGNMENT BY LMA UNDER STATEFUL ADDRESS CONFIGURATION
............................................................20
APPENDIX B. STATELESS ADDRESS AUTO-CONFIGURATION AND DUPLICATE ADDRESS
DETECTION......................................................20
APPENDIX C. AAA-BASED MECHANISM FOR ESTABLISHING PER-MN SA.....21
APPENDIX D. CONTEXT TRANSFER AND DATA FORWARDING between MAGs 22
APPENDIX E. FUTURE EXTENSIONS..................................23
E.1 PMIP CLIENT RELOCATION.....................................23
E.2 IPV4 DATA TUNNELING INSIDE IPV6
E.3 USAGE OF PER-MN PREFIXES
Singh et. al. Expires Septemeber 5, 2007 [Page 2]
Internet-Draft A Protocol for NETLMM March 5, 2007
IPR STATEMENTS................................................25
Disclaimer of Validity........................................25
COPYRIGHT NOTICE..............................................25
Acknowledgment.............................................. 26
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
documents are to be interpreted as described in RFC-2119 [1].
1.0 INTRODUCTION
In this draft, we describe a localized mobility management
solution that is network controlled and does not involve change in
IP address of the mobile node (MN) as it moves within a local
mobility domain (LMD). The IP address of the MN may be its Home IP
address (HoA) or a care-of-address (CoA) that has been obtained by
the MN for global mobility management. As long as the MN is within
one LMD, it is reachable on the same IP address, be it its HoA or
its CoA. We propose a localized mobility management solution that
employs a Mobile IPv6 home agent (HA), compliant with RFC 3775
[2], acting as the local mobility anchor (LMA). The proposed
mechanism allows a clean separation of the signaling function of
generating binding updates (BU) from the data plane function of
terminating the local mobility tunnel, while retaining RFC
compliance of MIPv6 HA. The entity generating BUs for a given
mobile node is fixed within the LMD and this allows for efficient
management of state information during mobility within the LMD.
2.0 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 RFC 2119
[1].
The following terminology and abbreviations are used
Mobile Node (MN)
An IPv6 host that may or may not be capable of Mobile IPv6.
Singh et. al. Expires September 5, 2007 [Page 3]
Internet-Draft A Protocol for NETLMM March 5, 2007
Mobile Access Gateway (MAG)
A functional IPv6 entity that terminates a specific edge link
towards the MN. The MAG also terminates host routed data traffic
from the Local Mobility Anchor for MNs currently located within
the edge link under the MAG's control, and forwards traffic from
MNs on the edge link under its control to the Local Mobility
Anchor.
Global Mobility Anchor (GMA)
A standard Mobile IPv6 Home Agent (HA) as described in RFC 3775
[2], capable of RADIUS [8] and can fetch MN-AAA keys from the AAA
server [9].
Local Mobility Anchor (LMA)
A standard Mobile IPv6 Home Agent (HA) as described in RFC 3775
[2] responsible for receiving Proxy Binding Updates (PBU)
from the PMIP client within a local mobility domain (LMD).
Local Mobility Domain (LMD)
An administrative network that contains several MAGs within which
an MN can maintain its IP address.
Proxy Binding Update (PBU)
A standard Mobile IPv6 Binding Update (BU) message, as described
in RFC 3775 [2], sent by the PMIP client whenever the MNs move
across MAGs within a local mobility domain (LMD).
Proxy Binding Acknowledgment (PBAck)
A standard Mobile IPv6 Binding Acknowledgment (BAck), as described
in RFC 3775 [2], message sent by the local mobility agent (LMA) in
response to a PBU message.
PMIP Client
A functional entity responsible for sending Proxy
Binding Update (PBU) message to the local mobility anchor (LMA)
on behalf of the MN whenever the MN moves across MAGs within a
local mobility domain (LMD).
Singh et. al. Expires September 5, 2007 [Page 4]
Internet-Draft A Protocol for NETLMM March 5, 2007
Local AAA Server
A standard AAA server located within a local mobility domain (LMD),
responsible for generating security keys required by the PMIP
client and local mobility anchor (LMA) for performing IKE.
Local AAA Client
A standard AAA client function located at the local mobility
anchor (LMA) and PMIP client, used for fetching the keys from
the local AAA server.
Proxy Home Address (pHoA)
An IP address acquired by the MN when it enters the LMD. This IP
address does not change as long as the MN remains within the LMD.
Proxy Care-of-Address (pCoA)
Refers to the IP address of the MAG to which the MN is currently
attached. Traffic destined for the MN's pHoA is tunneled to pCoA
by the LMA.
3.0 BRIEF DESCRIPTION OF SOLUTION
The proposed solution is based on a proxy Mobile IP (PMIP)
Technique, wherein a PMIP client sends binding update messages to
a local mobility anchor (LMA) to establish a mapping between the
MN's IP address and the IP address of the current MAG through
which the MN is reachable. A given LMA has several MAGs under it,
and these MAGs may or may not be co-located with base stations or
access points that terminate the layer 2 protocol with the MN.
The MN may be Mobile IP capable and may send BU messages for
inter-LMD mobility, i.e., global mobility. For local mobility, the
MAGs within an LMD make the MN believe that it is still within the
same subnet, and thus prevent the MN from initiating Mobile IP
messages. The MAGs in an LMD advertise the same prefix to the MN
in their router advertisement messages as the MN moves across
different MAGs. The figure 1 describes a local mobility domain
with standalone PMIP client.
Singh et. al. Expires September 5, 2007 [Page 5]
Internet-Draft A Protocol for NETLMM March 5, 2007
+-------+
| GMA |
+-------+
/ \
/ \
/ \
/ \
/ \
/ \
+-------+ +-------+
| LMA1 | | LMA2 |
+-------+ +-------+
/ \ |
/ \ |
+-------+ / \ |
| PMIP | / \ |
| client| / \ |
+-------+ / \ |
+-----+ +-----+ +-----+
| MAG1| | MAG2| | MAG |
+-----+ +-----+ +-----+
+--+ +--+
|MN|------------->|MN|
+--+ +--+
Figure 1) Local Mobility Domain with a stand alone PMIP client
This draft proposes a solution where the LMA is a Mobile IPv6 Home
Agent[2]. This allows reuse of existing standard IETF components
and avoids additional work of standardizing a new mobility anchor.
When an MAG realizes that an MN has made an L2 handoff to a cell
that it serves, the MAG triggers the PMIP client to initiate and
send a PBU to the LMA, which will establish a mapping between the
MN's current IP address and the MAG's IP address.
In general, the PMIP client may or may not be co-located with the
MAG. However, to avoid the security keys associated with the MN
from being transferred from one MAG to the other as the MN hands
off from one cell to another, this draft requires the PMIP client
to be fixed for a given MN for the duration that the MN is within
Singh et. al. Expires September 5, 2007 [Page 6]
Internet-Draft A Protocol for NETLMM March 5, 2007
that LMD. The sections that follow explain in detail the
procedures used in localized mobility management.
4.0 PROTOCOL DETAILS
The protocol consists of two parts: Procedures used during
initial attachment of an MN to the LMD, and procedures used during
intra-LMD mobility.
4.1 INITIAL ATTACHMENT
When the MN first connects to a MAG in the LMD, it is assumed to
have acquired an IP address from the GMA called its Home Address
(HoA). The process of obtaining HoA from the GMA is beyond the
scope of this document. This HoA may be required for the MN for
global mobility management using MIPv6. Note that the MN need not
be MIPv6 capable for localized mobility management to operate
within the LMD. We consider the general case where the MN is
MIPv6-capable, and the GMA and the LMA are different.
Figure 2 shows the set of procedures involved when the MN first
connects to a MAG, say MAG1, in the LMD.
1. The MN performs L2 attachment with an access point under MAG1.
The MAG1 obtains the MN identifier [3] based on this L2 attachment
procedure. The exact means by which MAG1 obtains the MN identifier
is outside the scope of this document.
2. After receiving the prefix as part of the router advertisement
from MAG1, the MN attempts to acquire another IP address, called
the Proxy Home Address (pHoA) associated with the advertised
prefix. The MN issues a DHCP request and a DHCP server assigns a
pHoA consistent with the advertised prefix. The MAG can act as
DHCP relay and learn the IP address assigned to the MN by
observing the response from the DHCP server. Another address
assignment mechanism where the pHoA is assigned by the LMA can
also be used as outlined in Appendix A. Alternatively, the pHoA
may instead be acquired through stateless auto-configuration as
described in Appendix B.
3. The MAG1 sends a trigger message to the PMIP client to send a
PBU message to the LMA. The trigger message contains the MN
identifier and the pHoA acquired by the MN. When there are
Singh et. al. Expires September 5, 2007 [Page 7]
Internet-Draft A Protocol for NETLMM March 5, 2007
multiple PMIP clients in the LMD, the PMIP client for an MN can be
assigned statically (e.g. based on the MN identifier) or
dynamically chosen by MAG1 by means outside the scope of this
draft.
4. The PMIP client constructs a PBU message to bind the MN's
acquired pHoA with the MAG1's IP address (pCoA). The PBU message
also contains the MN identifier option as specified in [3]. This
assumes that the PMIP client has established the required security
association (SA) with the LMA after suitably acquiring the keys
required for such an association.
The PMIP client sends the PBU message directly to the LMA and sets
the Alternate CoA field to the MAG1's IP address (pCoA), and the
source address will be the PMIP client's address
After the reception of PBU, the LMA processes the message
according to RFC 3775. After successful validation, the LMA
creates a binding to tunnel all packets destined for MN's pHoA to
the MAG1's IP address (pCoA), and also generates an appropriate
PBAck message destined to the PMIP client.
6. The PMIP client sends the PBAck Verification Status message to
the MAG1 after verifying the status of the PBack message sent by
the LMA within a suitably encapsulated container message. The
information in the PBAck message enables the MAG1 to start de-
tunneling any tunneled packets received from the LMA and
forwarding them to the MN.
7. A MIPv6 capable MN can then send a MIPv6 binding update (BU) to
the GMA for global mobility, thus establishing a binding between
the MN's HoA and the pHoA acquired by the MN in the LMD. The
MIPv6-capable MN subsequently receives a binding
acknowledgment(BAck) from the GMA.
Singh et. al. Expires September 5, 2007 [Page 8]
Internet-Draft A Protocol for NETLMM March 5, 2007
MN MAG1 PMIP LMA GMA
client
| | | | |
| | | | |
1.MN performs | | | |
L2 attachment | | | |
| | | | |
|<-2.Router Adv-| | | |
| | | | |
| 2.pHoA | | | |
|<=============>| | | |
| acquisition | | | |
| | | | |
| |--3.Trigger-->| | |
| | (MN ID, pHoA)| | |
| | |----4.PBU---->| |
| | |(MN ID,pHoA,pCoA) |
| | | | |
| | |<---5.PBAck---| |
| | | | |
| |<---6.PBAck---| | |
| | verification | | |
| | status | | |
| | | | |
|-------------------------7.BU----------------------------->|
| | | | |
|<-----------------------7.BAck-----------------------------|
| | | | |
| | forward packets | |
|<==============|<============================|<============|
| | | | |
Figure 2) Procedure for MN's initial attachment to LMD
4.2 INTRA-LMD MOBILITY
Figure 3 shows the procedures involved when the MN moves across
MAGs within the LMD.
1. When the MN hands off from MAG1 to MAG2, the MAG2 also
advertises the same prefix to the MN as was sent by MAG1 in its
router advertisement to that MN. Due to this, the MN does not try
to acquire a new address or invoke global mobility procedures. The
MAG1 transfers the MN's context and potentially data packets to
MAG2. For example, context transfer can be performed using Context
Transfer Protocol (CXTP) [10]. The MN's context will contain the
MN identifier, the pHoA that was configured by the MN during its
initial attachment to the LMD, and the location of the PMIP client
Singh et. al. Expires September 5, 2007 [Page 9]
Internet-Draft A Protocol for NETLMM March 5, 2007
for the MN. The location of the PMIP client need not be
transferred if there is only one PMIP client in the LMD or if the
PMIP client can be determined based on the MN identifier.
2. The MAG2 triggers the PMIP client to send a PBU. The trigger to
the PMIP client, as before, contains the MN identifier and the
pHoA. The PMIP client will check whether the same MN identifier -
pHoA combination exists in its cache. In the intra-LMD mobility
case, the cache entry will be found. If the cache entry is found,
the PMIP client will use this trigger to send a new PBU.
3. The PMIP client constructs and sends a PBU message to the LMA
for binding the pHoA to the MAG2's IP address (new pCoA). The MN
identifier need not be sent as part of this PBU message.
4. The LMA now binds the MN's pHoA to MAG2's IP address (new pCoA)
and responds with a PBAck message. Henceforth, the packets
destined to MN's pHoA will be tunneled to the MAG2's address.
5. The PBAck verification status is sent to MAG2 as a response to
the trigger message.
The PMIP client can be a separate entity as shown in Figure 1
having a centralized control of the security keys involved in
sending the PBU messages. Alternatively, the PMIP client can be
co-located at one of the MAGs. This MAG, for example can be the
one where the MN first acquired its IP address in the LMD. Even in
this case the security keys involved in the Mobile IP signaling
shall be anchored at a single MAG. During handoffs, only the
tunnel end-point (i.e. the data plane) will be migrated to the new
MAG, whereas the PBU message (i.e. the control-plane signaling)
will still be generated at the anchored MAG. In addition, the
security keys associated with the signaling shall not be
transferred across MAGs during the handoff. Because the PBUs for a
given MN always originate from the same PMIP client as long as the
MN is within the LMD, the sequence numbers in the PBU messages as
defined in RFC3775 [2] are sufficient to ensure ordering of
messages. Thus there is no need to add extensions to the MIPv6 BU
or BAck messages, such as timestamp extensions, to resolve any
potential race conditions that might arise if multiple entities
send BUs for a given MN.
Singh et. al. Expires September 5, 2007 [Page 10]
Internet-Draft A Protocol for NETLMM March 5, 2007
MN MAG1 MAG2 PMIP LMA
client
| | | | |
|----------1.L2 Handoff------->| | |
| | | | |
| | 1.MN context | | |
| |<====&data===>| | |
| | transfer | | |
| | |---2.Trigger-->| |
| | | (MN ID, pHoA) | |
| | | | |
| | | |---3.PBU--->|
| | | |(pHoA, pCoA)|
| | | | |
| | | |<--4.PBAck--|
| | | | |
| | |<---5.PBAck----| |
| | | verification | |
| | | status | |
| | | | |
| | forward packets | |
|<=============================|<===========================|
| | | | |
Figure 3) Intra-LMD handoff procedure
4.3 SECURITY ASSOCIATION BETWEEN PMIP CLIENT AND LMA
Security is provided for the PBU messages by having the LMA
maintain a separate SA for each MN. The method by which the PMIP
client obtains the security credentials of the MN is outside the
scope of this document. However, one mechanism that depends on AAA
infrastructure is shown in Appendix C. It is possible that the LMA
can be accessed through different PMIP clients, for example, if
the PMIP client is co-located at the MAG. For these cases, the
mechanism described in Appendix C is well suited as it is scalable
with the number of PMIP clients in the LMD. The fact that the PMIP
client obtained the security keys corresponding to the MN
automatically implies that the PMIP client is authorized to send
PBUs on behalf of the MN.
Alternatively, instead of using per-MN SAs, security associations
between every PMIP client and the LMA can be established. While
using per-MN SA is fully compliant with RFC 3775 and hence allows
complete reuse of MIPv6 HA as the LMA, using per-PMIP client SA
may reduce the number of SAs required but will require
modifications to the MIPv6 HA before it can be used as the LMA.
Singh et. al. Expires September 5, 2007 [Page 11]
Internet-Draft A Protocol for NETLMM March 5, 2007
4.4 INTER-LMA MOBILITY
We assume a general situation where a given MAG may be able to
have tunnels with multiple LMAs, so that LMD can be overlapping.
When it is desired to change the anchor point of the mobile to a
new LMA (either when a mobile hands over to a different MAG, or
even when the mobile remains under the same MAG), the presence of
the new LMA is made known to the MN by advertising a different
prefix to the MN. Such a change of LMAs can be carried out for
routing efficiency reason. The PMIP client used to establish a
proxy binding to the new LMA may be the same as with the old LMA,
or a new PMIP client may be invoked. In either case, a new MN-
specific SA may need to be established between the appropriate
PMIP client and the new LMA for securing PBU messages when per-MN
SA is used. The MN also needs to acquire a new pHoA consistent
with the new link prefix advertised by the MAG. As an alternative,
the same AAA based mechanism as described in Appendix B can be
used.
4.5 RELOCATION OF PMIP CLIENT
The mobility management solution proposed in this document allows
multiple PMIP clients to be present in the LMD. But the PMIP
client for a given MN is fixed within the LMD for the lifetime of
the MN. This ensures that the security keys for that MN is
anchored at a single node and not transferred between PMIP clients
when per-MN SA is used to secure PBU messages. The data plane,
however, is migrated to a different MAG when the MN moves across
MAGs. In addition, data forwarding is supported from source MAG to
target MAG during handoff and hence no packet losses are expected
due to the signaling exchange between the current MAG and the PMIP
client. The MN continues to receive the packets forwarded from the
source to target MAG while the LMA is being updated. In case
relocation of PMIP client is required for other reasons, a
mechanism as described in Appendix E.1 may be used.
4.6 HANDLING OF MIPv6 CAPABLE MNs IN THE LMD
In the solution proposed above, all the MAGs in the LMD advertise
the same link prefix to a given MN. All MNs, irrespective of
whether or not they are MIPv6 capable, are managed by PMIP-based
localized mobility management solution as long as they remain
Singh et. al. Expires September 5, 2007 [Page 12]
Internet-Draft A Protocol for NETLMM March 5, 2007
within the LMD. The MIPv6 capability of an MN is used only when it
moves across LMDs, in order to update the binding with the GMA.
4.7 PMIP CLIENT CONSIDERATIONS
The PMIP client functional entity is responsible for sending PBU
messages to the LMA for binding the pHoA of the MN with the IP
address of the MAG (pCoA) to which the MN is currently connected.
The PMIP client sends the PBU message after receiving the trigger
from the MAG. The trigger can be for an MN that is performing
initial attachment or for an MN that has moved to a different MAG
within the LMD. The trigger provides the MN identifier (and the pHoA
of the MN, if acquired by DHCP).
The PMIP client first checks if it has already sent a PBU for the MN
with the received MN identifier. This can be done, for example, by
maintaining a binding cache that contains the MN identifier, pHoA,
and the MAG's IP address (pCoA) for those MNs for whom PBUs have
been sent and by checking if the MN identifier received as part of
the trigger already exists in the cache.
If no entry exists in the cache for the received MN identifier, the
PMIP client considers this MN as performing initial attachment to
the LMD. It then forms a PBU message and sends it to the LMA. In
case an entry exists in its cache for the received MN identifier,
the PMIP client further checks if the pHoA in the received trigger
matches with the pHoA against this MN identifier in the cache. If it
does not, this is considered as an error and an error status is
reported to the MAG. In case the right combination of MN identifier
and pHoA exists, the MN is considered to have moved to a different
MAG within the LMD. Consequently, an appropriate PBU message is sent
to the LMA.
After receiving the PBAck message from the LMA, the PMIP client
needs to process it and respond to the MAG with appropriate status
information.
4.8 LMA CONSIDERATIONS
The mobility management solution described in this document allows
reusing MIPv6 HA as the LMA without any additional modifications.
Some of the mechanisms described in the appendices may require
modifications to the MIPv6 HA behaviour, as indicated in the
relevant appendices.
Singh et. al. Expires September 5, 2007 [Page 13]
Internet-Draft A Protocol for NETLMM March 5, 2007
4.9 MAG - PMIP CLIENT INTERACTION
This document describes clean separation between PMIP client that
generates the PBU signaling and the MAG that acts as the tunnel
end-point. It also suggests that PMIP client for a given MN must
be anchored at a single entity while the MN moves from one MAG to
other. A light-weight protocol is defined between PMIP client and
MAG to enable interaction between them. The protocol between PMIP
client and MAG defines two messages, namely Trigger and
Notification. Trigger Message is used by MAG to inform PMIP client
that an MN has associated with it, either during initial network
entry or after inter-MAG handoff. Notification Message is used by
PMIP client to inform MAG that the Binding Update procedure with
LMA has been completed. As part of Notification message, PMIP
client encapsulates the Binding Ack / Error message received from
the LMA and delivers it to MAG. After receiving the Binding Ack
through the Notification Message, the MAG creates the appropriate
tunnel state required for tunneling and de-tunneling of bearer
packets between MAG and LMA. A Transaction Number is used to
correlate Trigger and Notification messages.
The format of Trigger and Notification messages are defined the
in following sections
4.9.1 TRIGGER MESSAGE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Ver| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Fields:
Type : 0x1
Length of message in units of octets
Version: 3 bit versions. For this specification ver. is set to 1.
Singh et. al. Expires September 5, 2007 [Page 14]
Internet-Draft A Protocol for NETLMM March 5, 2007
Reserved: Initialized to zero and ignored on receipt
Transaction number: Allows the notification message to be matched
with the trigger message
4.9.2 NOTIFICATION MESSAGE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Ver| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
Fields:
Type : 0x2
Length of message in units of octets
Version: 3 bit versions. For this specification ver. is set to 1.
Reserved: Initialized to zero and ignored on receipt
Transaction number: Allows the notification message to be matched
with the trigger message
4.9.3. Options Format
All options are of the following form:
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 Len | Option Data . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type: 8-bit identifier of the type of option. The options
defined in this document are L2-ID option, IP address option and
container option. L2-ID option is used to encode MN Identifier, IP
Singh et. al. Expires September 5, 2007 [Page 15]
Internet-Draft A Protocol for NETLMM March 5, 2007
address option is used to encode MN home address, and container
sub-option is used to encapsulate PBAck messages from PMIP client
to MAG.
4.9.3. MAG-PMIP client Transport
This document suggests that implementation of PMIP client MAG
protocol SHOULD use the Stream Control Transport Protocol (SCTP) [5]
as the transport protocol. SCTP supports congestion control,
fragmentation, and partial retransmission based on a programmable
retransmission timer. The SCTP Payload Data Chunk carries the
Trigger and Notification messages. User Data part of each SCTP
message contains the Trigger and Notification messages as described
above. A single stream is used for PMIP-MAG protocol with in-
sequence delivery of SCTP messages. Each message, unless
fragmented, corresponds to a single Trigger or Notification message.
A single stream provides simplicity. The Payload Protocol Identifier
in the SCTP header is 'PMIP-MAG'. PMIP-MAG interface uses a PMIP-
MAG SCTP port to be identified by IANA. The format of Payload Data
Chunk taken from SCTP RFC is shown in the following diagram.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'U' bit The Unordered bit. MUST be set to 0 (zero).
'B' bit The Beginning fragment bit. See [5].
'E' bit The Ending fragment bit. See [5].
TSN Transmission Sequence Number. See [5].
Singh et. al. Expires September 5, 2007 [Page 16]
Internet-Draft A Protocol for NETLMM March 5, 2007
Stream Identifier S
Identifies the SCTP stream.
Stream Sequence Number n
Sequence number. See [5].
Payload Protocol Identifier
Set to 'PMIP-MAG'.
User Data Contains the PMIP message.
4.9.4. MAG-PMIP client Security
To prevent the information from being compromised, the Trigger
and Notification messages between PMIP client and MAG MUST be
authenticated. The messages MAY also be encrypted for privacy of
the information, if required. The PMIP client and the MAG engaging
in the PMIP-MAG protocol MUST use IKE [7] to negotiate an IPsec ESP
[6] security association for message authentication. If
confidentiality is desired, the PMIP client and the MAG MUST
additionally negotiate an ESP security association for encryption.
Replay protection SHOULD also be enabled with IKE. To protect PMIP
client-MAG protocol messages between PMIP client and MAG, IPsec ESP
MUST be used with a non-null integrity protection and origin
authentication algorithm and SHOULD be used with a non-null
encryption algorithm for protecting the confidentiality of the
Trigger and Notify message.
5.0 IANA CONSIDERATIONS
This document defines a transport protocol that runs over SCTP
between PMIP client and MAG. So, the PMIP client and MAG would
need a well known SCTP port to communicate with each other. The
port number for the SCTP port for PMIP client-MAG protocol use
should be defined by IANA.
6.0 SECURITY CONSIDERATIONS
To avoid security vulnerabilities, the security keys and the
IPSec SA are anchored at a single node, i.e., PMIP client, for
handoffs. Even when the PMIP client is at a MAG, there is an
Singh et. al. Expires September 5, 2007 [Page 17]
Internet-Draft A Protocol for NETLMM March 5, 2007
anchored MAG that holds the MN's security keys, which may be
different for different MNs. There is a separate IPSec SA for each
MN, even though several MNs may use the same LMA and PMIP
client. Alternatively, a single IPSec SA between a PMIP client and
an LMA may be used to protect the signaling for all the MNs being
handled by the PMIP client. IPSEC ESP is used to protect PMIP
client to MAG protocol as defined in section 4.9.4.
7.0 NORMATIVE REFERENCES
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[2] D. Johnson et al., "Mobility Support in IPv6", RFC 3775, June
2004
[3] A. Patel et al., "Mobile Node Identifier Option for Mobile IPv6
(MIPv6) ", RFC 4283, November 2005
[4] J. Arkko et al., "Using IPSec to Protect Mobile IPv6 Signaling
between Mobile Nodes and Home Agents", RFC 3776, June 2004
[5]Stewart, R. et al. "Stream Control Transmission Protocol",
RFC 2960, October 2000.
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[7] D. Harkins et al., "The Internet Key Exchange (IKE)", RFC 2409,
November 1998
8.0 INFORMATIVE REFERENCES
[8] C. Rigney et al., "Remote Authentication Dial In User Service
(RADIUS)", RFC 2865, June 2000
[9] C. de Laat et al., "Generic AAA Architecture", RFC 2903, August
2000
[10] J. Loughney et al., "Context Transfer Protocol", RFC 4067, July
2005
Singh et. al. Expires Sepetember 5, 2007 [Page 18]
Internet-Draft A Protocol for NETLMM March 5, 2007
[11] S. Thomson et al., "IPv6 Stateless Address Autoconfiguration",
RFC 2462, December 1998
[12] P. Calhoun et al., "Diameter Base Protocol", RFC 3588,September
9.0 AUTHORS' ADDRESSES
Anand Bedekar
Motorola Inc
1501 West Shure Dr,
Arlington Heights 60004
USA
Phone: +1 847-632-3046
Email: anand.bedekar@motorola.com
Ajoy Singh
Motorola Inc
1501 West Shure Dr,
Arlington Heights 60004
USA
Phone: +1 847-632-6941
Email: asingh1@email.mot.com
Vinod Kumar
Motorola India Electronics Limited
66/1, Plot No. 5,
Bagmane Tech Park
CV Raman Nagar Post
Bangalore 560093
India
Phone: +91-80-26012308
Email: vinodkumar@motorola.com
Suresh Kalyanasundaram
Motorola India Electronics Limited
66/1, Plot No. 5,
Bagmane Tech Park
CV Raman Nagar Post
Bangalore 560093
India
Phone: +91-80-26012308
Singh et. al. Expires Sepetember 5, 2007 [Page 19]
Internet-Draft A Protocol for NETLMM March 5, 2007
Email: Suresh.Kalyanasundaram@motorola.com
APPENDIX A. pHoA ASSIGNMENT BY LMA UNDER STATEFUL ADDRESS CONFIGURATION
Under stateful pHoA address configuration, the MN issues a
DHCP request. The MAG to which the MN is currently attached acts
as a proxy DHCP server. That is, it receives the DHCP request and
will send a DHCP reply to the MN, but it will obtain the address
to assign to the MN in the following manner. The MAG sends a
Trigger message to the PMIP client to send a PBU on behalf of the
MN. This Trigger message contains the MN identifier that may be
obtained when the MN makes L2 attachment. The PBU sent to the LMA
contains the MN identifier but pHoA field remains ALL-ZEROS. The
LMA, as part of the PBAck message, assigns a pHoA for the MN. This
address is communicated by the PMIP client to the MAG in the
Notification message. The MAG, sends this address as part of the
DHCP reply to the MN. This method of LMA assigning IP addresses
for the MN requires that the MIPv6 HA support dynamic home address
assignment, a capability not present in [2].
APPENDIX B. STATELESS ADDRESS AUTO-CONFIGURATION AND DUPLICATE ADDRESS
DETECTION
Instead of the DHCP-based procedure, the pHoA can be acquired
by an MN during initial attachment using stateless address auto-
configuration. In stateless configuration, the MN configures its
own pHoA based on the prefix advertised by the MAG and sends a
Neighbor Solicitation (NS) message as specified in [11]. The MAG
to which the MN is currently attached triggers the PMIP client to
send a PBU. The trigger contains a flag indicating to the PMIP
client whether the address is acquired through stateful or
stateless configuration and hence determines the need for DAD. The
PMIP client verifies if the pHoA configured by the MN is unique by
checking its cache and determining if any MN with a different MN
identifier has already acquired the same address. If no
conflicting address is found, and if there are multiple PMIP
clients in the LMD, the PMIP client sends a "conflict detection
request" to other PMIP clients in the LMD to check for uniqueness.
This request can also be sent immediately after receiving the
trigger from the MAG. The request contains the MN identifier and
the pHoA configured by the MN.
Singh et. al. Expires September 5, 2007 [Page 20]
Internet-Draft A Protocol for NETLMM March 5, 2007
The other PMIP clients in the LMD check for uniqueness in a
similar fashion as above and respond with "conflict detected" or
"no conflict" message to the original PMIP client. In case the
address is not unique, the PMIP client informs the MAG with PBAck
verification status message that has "address conflict detected"
as the reason. Otherwise, the PMIP client sends PBU for the MN.
Thus address conflicts are detected by the PMIP client (if there
is only one in the LMD), or by inter-PMIP client interaction (if
there are multiple PMIP clients in the LMD).
Note that when the LMA receives the PBU, it will perform DAD as
described in RFC 3775 to ensure that no other MN for whom the LMA
is acting as MIPv6 HA is using the same address. If the prefixes
advertised to the MNs are such that a particular prefix is
routable only to a single LMA, then the PMIP client can depend on
the DAD performed by the LMA itself, and no further action by the
PMIP client is required. The execution of DAD by the PMIP client
(or by interaction of multiple PMIP clients) is required only if
any particular prefix may be routable to more than one LMA.
If the MAGs in the LMD advertise the LMA's prefix, the addresses
acquired using stateless auto-configuration will be suitable for
point-to-point links between the MN and MAG. Another alternative
is for the MAG to send a separate prefix for each MN and the MN
can acquire pHoA consistent with this per-MN prefix. A prefix of
length 128 bits eliminates the need for DAD and does not invoke
any shared-link procedures while a shorter prefix will lead to
wastage of address space.
APPENDIX C. AAA-BASED MECHANISM FOR ESTABLISHING PER-MN SA
The following mechanism can be used to dynamically establish per-MN
SA between the PMIP client and the LMA. For carrying out this
mechanism the LMA and the PMIP client shall have local AAA client
function. This scheme can be used when the PMIP client is either a
stand-alone entity or co-located with the MAG. This scheme uses a
separate key for a separate IPSec SA for each MN as in [4], even
when they use the same PMIP client and LMA. Note that we assume that
the PMIP client for a given MN remains fixed after the binding is
established for that MN at the LMA.
The AAA client colocated with the PMIP client can fetch the key
required for establishing the SA with the LMA from the local AAA
Singh et. al. Expires September 5, 2007 [Page 21]
Internet-Draft A Protocol for NETLMM March 5, 2007
server. The key fetch transaction may be triggered by other events
related to the MN's attempt to access the MAG, for example the
authentication of the MN for access to the domain. In cases where
the local AAA server is either the home AAA server of the MN or a
AAA proxy server in the MN's authentication, further synchronization
of the key fetching with the MN's authentication process may be
possible.
After getting the key from the local AAA server, the PMIP client
should initiate Internet Key Exchange (IKE) [7] with the LMA. The
LMA in turn, using its associated AAA client, queries the local AAA
server and fetches the key required for the IKE processing. The
local AAA server should remember the key that has been sent to the
PMIP client until the LMA asks for it. Following IKE, the PMIP
client can send the PBU message. The IPSec endpoint corresponding to
the MN's pHoA for the SA is at the PMIP client instead of the MN.
For the interaction between the local AAA server, PMIP client, and
LMA, standard AAA protocols, such as, RADIUS [8] or DIAMETER [12]
can be used.
When the MN-specific SA is used, the key for this SA is provided to
the PMIP client by the AAA server only after verifying that the PMIP
client is authorized to send PBUs for that MN (e.g., at the time the
MN is authenticated in to the domain for link-layer access). The
fact that the AAA server provides the MN-specific key for that PMIP
client to the LMA during IKE procedure also serves as validation
that the PMIP client is authorized to send BUs for that MN. In this
model of PMIP client anchored for a given MN, the LMA will have to
contact the AAA server once per MN.
In the alternative model where there is a single SA between a PMIP
client and an LMA to protect the BUs for all MNs, this AAA procedure
can be used to bootstrap the IPSec security association between the
PMIP client and the LMA. This mainly helps in simplifying network
configuration, by avoiding the need to pre-distribute shared keys
for every pair of PMIP client and LMA. In this model, if there are
multiple PMIP clients in the domain (e.g. if each MAG is collocated
with a PMIP client), the HA may additionally need to contact the AAA
server once per MN in order to obtain a list of PMIP clients that
are authorized to send BUs for that MN.
APPENDIX D. CONTEXT TRANSFER AND DATA FORWARDING between MAGs
Singh et. al. Expires September 5, 2007 [Page 22]
Internet-Draft A Protocol for NETLMM March 5, 2007
As noted in section 4.2, when an MN hands over from MAG1 to MAG2,
MAG2 will send a trigger message to the PMIP client for that MN to
send a PBU to the LMA. MAG2 minimally needs the MN identifier in
order to send the trigger message to the PMIP client. This may be
obtained by MAG2 directly from the MN through L2 attachment
procedures. However, in terms of handover latency, it would be
beneficial if MAG2 could obtain the MN Identifier prior to the
completion of the L2 attach procedure. Additionally, if there are
multiple PMIP clients in the domain (e.g. if each MAG is
collocated with a PMIP client), then MAG2 needs to know the
address of the PMIP client for that MN in order to send the PMIP
Furthermore, it would be useful for the MAG2 to provide the pHoA
of the MN in the trigger message to aid the PMIP client in
performing some error checks. Since all these information elements
are available at MAG1, MAG1 should forward such context
information for the MN to MAG2. The Context Transfer Protocol
(CXTP) [10] can be used to accomplish this, using suitably defined
feature profile types for CXTP.
In addition to context transfer, it is also useful to have data
forwarding from MAG1 to MAG2 during the MN's handover. In the
absence of such data forwarding, the MN would not receive any data
through MAG2 until the PBU message was processed at the LMA,
resulting in increased handover latency. In order to eliminate
this latency, MAG1 should forward data for the MN to MAG2 during
the handover. This data forwarding should include data buffered at
MAG1 at the time of initiation of the handover, plus any
subsequent data that arrived at the MAG1. Thus data flow for the
MN can be resumed immediately on completion of the L2 attachment
procedures, without waiting for completion of the PBU signaling to
the LMA.
APPENDIX E. FUTURE EXTENSIONS
E.1 PMIP CLIENT RELOCATION
If there are multiple PMIP clients in the domain, and if PMIP
client relocation for a given MN is required, the MAG can choose a
new PMIP client to serve the MN. The PMIP client has to establish
a new MN-specific SA with the LMA if per-MN SA is employed. The
new PMIP client can use the AAA-based solution as specified in
Appendix C for establishing this SA. This will again require
modifications to the behavior of a MIPv6 HA in order to function
Singh et. al. Expires September 5, 2007 [Page 23]
Internet-Draft A Protocol for NETLMM March 5, 2007
as an LMA, since the LMA will now receive PBUs for the same MN
through different SAs.
E.2 IPV4 DATA TUNNELING INSIDE IPV6
While the situation considered in the draft assumes only IPv6
capability at all the elements, it may be of interest to support
IPv4-capable mobiles with IPv6-enabled network elements. For
example, it may be of interest to support access to the IPv4
Internet for an IPv4-capable mobile, even when all the network
elements in the LMD are IPv6-capable. One possible solution for
this scenario is to use a dual-stack LMA that acts as a gateway to
the IPv4 Internet while providing network localized mobility using
IPv6 inside the LMD. For example, the PBU sent by the PMIP client
to the LMA can include extensions to carry the IPv4 address of the
MN for which IPv4 access is desired. The LMA would then tunnel all
IPv4 packets destined to this IPv4 address to the pCoA of the PBU
(i.e. the address of the MAG). The MAG would de-tunnel the IPv6
packets received from the LMA to recover the IPv4 packet, and
forward the IPv4 packet to the MN.
Note that in order to provide this functionality, extensions need
to be defined to Mobile IPv6 messages and modifications to the
behavior of a MIPv6 HA are required in order to provide such
capabilities.
E.3 USAGE OF PER-MN PREFIXES
In some situations it may be of interest to allocate each MN a
unique prefix, instead of advertising a single prefix (e.g. the
LMA's prefix) to multiple MNs. This would be useful, for example,
when the MN itself is a router for a moving subnet, or when the MN
may have multiple interfaces on the same link, etc. Another reason
to use per-MN prefixes is to avoid the need for DAD and NS in
situations where the physical link is shared by multiple MNs
(rather than a point-to-point link between the MN and the MAG).
This can create the illusion of non-overlapping links for
individual MNs even when the physical link is shared between
multiple MNs. The allocation of per-MN prefixes can be
accommodated by the model of this draft.
One way to handle tunneling for multiple addresses configured by
the MN from the per-MN prefix is to include the entire prefix
Singh et. al. Expires September 5, 2007 [Page 24]
Internet-Draft A Protocol for NETLMM March 5, 2007
(rather than just a single pHoA) in the PBU sent by the PMIP
client to the LMA. The LMA would then install a route for the
entire prefix, rather than a route for a single pHoA. This can be
accommodated in the model proposed in this draft by a suitable
extension to the Mobile IPv6 messages to carry prefixes, and a
suitable modification to the MIPv6 HA behavior for use as the LMA.
IPR STATEMENTS
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.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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.
COPYRIGHT NOTICE
Singh et. al. Expires September 5, 2007 [Page 25]
Internet-Draft A Protocol for NETLMM March 5, 2007
"Copyright (C) The IETF Trust (2007). All Rights Reserved.
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 translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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."
Acknowledgment
We would like to thank Vijay Raman for editing first version of this
draft. We would also like to thank Sebastian Thalanany, Pierrick SEITE,
Christian Vogt, Pete McCann, Petrescu Alexandru, Julien Laganier, Behcet
Sarikaya, Phil Roberts, Vidya Narayanan, Marco Liebsch and other members of
NETLMM WG for reviewing and providing feedback on the draft.
Singh et. al. Expires September 5, 2007 [Page 26]