Internet DRAFT - draft-gundavelli-netlmm-mip6-proxy
draft-gundavelli-netlmm-mip6-proxy
NETLMM BOF S. Gundavelli
Internet-Draft K. Leung
Expires: May 12, 2006 Cisco Systems
November 8, 2005
Localized Mobility Management using Proxy Mobile IPv6
draft-gundavelli-netlmm-mip6-proxy-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Localized Mobility Management (LMM) requires mobility support for a
mobile station within a restricted and topologically localized
portion of the network. Mobile IPv6 is a standardized mobility
protocol for IPv6 that can be extended to address the local mobility
management requirements. This document describes a solution based on
Proxy Mobile IPv6 scheme by introducing new functional entities and
extensions to the protocol and by restricting the mobility signaling
to only certain entities in the network.
Gundavelli & Leung Expires May 12, 2006 [Page 1]
Internet-Draft LMM using MIPv6 November 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Overview of Proxy Mobile IPv6 . . . . . . . . . . . . . . . . 5
3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. LMM Domain Architecture . . . . . . . . . . . . . . . . . 7
3.3. New Functional Elements . . . . . . . . . . . . . . . . . 9
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . . 10
4.2. Proxy Binding Acknowledgement . . . . . . . . . . . . . . 11
4.3. Binding Cache Confirmation Option . . . . . . . . . . . . 11
5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Binding Acknowledgement Status Values . . . . . . . . . . 12
6. Proxy Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Network Access Authentication . . . . . . . . . . . . . . 14
6.2. Router and Neighbor Discovery with Local Network
Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Address Configuration . . . . . . . . . . . . . . . . . . 16
6.4. Resource Cleanup . . . . . . . . . . . . . . . . . . . . . 20
7. Mobility Proxy Agent Operation . . . . . . . . . . . . . . . . 21
7.1. Conceptual Data Structures at the MPA . . . . . . . . . . 21
7.2. Mobility Signaling for Mobile Station . . . . . . . . . . 22
7.3. Establishment of Bi-Directional Tunnel . . . . . . . . . . 23
8. Mobile Station Operation . . . . . . . . . . . . . . . . . . . 23
8.1. Booting up in a LMM Domain . . . . . . . . . . . . . . . . 24
8.2. Moving to a New MPA . . . . . . . . . . . . . . . . . . . 24
8.3. Packet forwarding . . . . . . . . . . . . . . . . . . . . 25
8.4. Moving to a New LMM Domain . . . . . . . . . . . . . . . . 26
9. LMAP Operation . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Processing Proxy Binding Update . . . . . . . . . . . . . 26
9.2. Packet interceptions . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11. Security Considerations . . . . . . . . . . . . . . . . . . . 27
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
13. Normative References . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 30
Gundavelli & Leung Expires May 12, 2006 [Page 2]
Internet-Draft LMM using MIPv6 November 2005
1. Introduction
The need for Localized Mobility Management is justified in [5] and
the issues are identified in [4]. In brief, a solution is needed to
provide mobility for a Mobile Station that minimizes handover
latency, avoids signaling overhead on the air-link, and hides
handover event within LMM domain from global mobility. These
objectives should be achieved without host support in the mobility
signaling or complex security interactions between the host and
network.
The solution described in this document accomplishes the feats by
introducing a proxy Mobility Agent, called Mobile Proxy Agent (MPA),
that signals to a Local Mobility Agent Point (a.k.a. Home Agent) to
set up a tunnel between them for traffic to and from the Mobile
Station. An crude analogy is a Mobile Router - which happens to be
the fixed Access Router with MPA function - that registers a Host-
Specific-Prefix (i.e. ::/128) to its Home Agent whenever the Mobile
Router detects a Local Fixed Node with a different prefix than the
attached Mobile Network Prefix [14]. In this case, the host has no
idea that it is moving. In actuality, the MPA is spoofing the host
(to believe that it remains on the same network) and updating the
host's location to the Local Mobility Agent Point, a node that is
typically dynamically assigned by the network to be near the host.
2. Conventions used in this document
The keywords "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 [4].
The following new terminology and abbreviations are introduced in
this document and all other general mobility related terms as
defined in Mobile IPv6 specification [2].
Mobility Station (MS)
Any IPv6 host that has the ability to physically roam across
different networks. The Mobile Station is not required to have
the Mobile IPv6 protocol stack.
Local Mobility Anchor Point (LMAP)
Gundavelli & Leung Expires May 12, 2006 [Page 3]
Internet-Draft LMM using MIPv6 November 2005
The Mobile IPv6 entity which functions as a local Home Agent to
anchor data traffic for a Mobile Station.
Mobility Proxy Agent (MPA)
The Mobile IPv6 entity that offers proxy mobility service for a
Mobile Station by performing registration function on the
host's behalf. The MPA function is provided by the Access
Router, which the Mobile Station is attached to in the access
network.
Base Station (BS)
A Layer 2 bridging device connected to the MPA offering
wireless connectivity to the Mobile Station.
Local Network Prefix (LNP)
The network prefix that is assigned to a mobile station in a
LMM domain. This prefix is attached to the interface of the
Mobile Station's LMA. Note that the LNP is analogous to the
Home Link Prefix in MIPv6.
Local Address (LoA)
The address that is owned by the Mobile Station in a LMM
domain. The address belongs to the prefix owned by the Mobile
Station's LMAP. The Mobile Station will be able to use this
address for roaming within the LMM domain. Note that the LoA
is analogous to the Home Address in MIPv6.
Local Home Network (LHN)
The Mobile Station in a LMM domain is logically anchored to a
LMAP and the Local Address of the Mobile Station belongs to a
prefix owned by the LMA. The prefix is attached to the
interface of the LMAP and that is the Local Home Network for
the Mobile Station. Note that the LHN is analogous to the Home
Link in MIPv6.
Proxy Binding Update (PBU)
A Binding Update message from the MPA instructing the Mobile
Station's LMAP to register the current location information.
Proxy Binding Acknowledgment(PBA)
Gundavelli & Leung Expires May 12, 2006 [Page 4]
Internet-Draft LMM using MIPv6 November 2005
A Binding Acknowledgment message from the LMAP to the MPA in
response to the PBU message.
3. Overview of Proxy Mobile IPv6
3.1. Design Goals
Proxy Mobile IPv6 is designed to satisfy the requirements of LMM [5].
In addition, the solution leverages well-studied specification and
highly available implementations. Only incremental enhancements are
added to Mobile IPv6 protocol to enrich its breadth to support both
global mobility and local mobility. For example, a Home Agent can
anchor Mobile Stations roaming within an LMM domain and Mobile Nodes
roaming into other domains.
The Localized Mobility Management solution defined in this document
has the following design goals:
1. Handover Performance Improvement
The Layer 1 and Layer 2 issues involved in handover should be
covered in IEEE 802.21 which interacts with the IETF Detecting
Network Attachment WG. It is assumed that these layers can
provide optimized handover performance, and such functions are
outside the scope of this document.
From the network layer perspective, the Mobile Station is always
authenticated when accessing the network (ASSUMPTION). When
authentication completes for access or handover, this triggers the
MPA to notify the LMAP. The important factor is the proximity of
the LMAP to the MPA. In this scheme, the LMAP is dynamically
assigned based on the location of the MS. The AAA Server can
index the MPA's address to find the nearest LMAP for assignment,
or the MPA is provisioned with its nearest LMAP, or some other
scheme. Further optimization such as MPA to MPA tunneling is not
required in the base LMM solution.
2. Reduction in Handover-related Signaling Volume
Mobility-related signaling over the air-link is eliminated. The
Mobile Station performs normal IPv6 network attachment activities
and learns that it remains on the same network, the Local Home
Network which is anchored by LMAP.
3. Location Privacy
Gundavelli & Leung Expires May 12, 2006 [Page 5]
Internet-Draft LMM using MIPv6 November 2005
The corresponding nodes that are communicating or have established
flows with the Mobile Station must not be able to determine the
current location information of the Mobile Station. Since the
LMAP is anchoring the Local Address, movement within the LMM
domain is hidden from the corresponding node.
4. Efficient Use of Wireless Resources
There is no mobility signaling or tunneling header on the air-
link. All signaling and tunneling are inside the network and only
the original packet traverse the air-link.
5. Reduction of Signaling Overhead in the Network
When a Mobile Station moves to a new MPA, the minimal number of
messages are used to update the location on the LMAP and release
the resources on the previous MPA. Due to the event driven states
(e.g. MS is at MPA or arrived at another MPA), there is no need
for chatty binding refresh messages. This method can
significantly reduce the number of signaling messages compared to
Mobile IPv6.
6. No Extra Security Between the Mobile Node and Network
Because the Mobile Station is not participating in the mobility
signaling, there is no need to set up any security credentials to
mobility authorization. The network nodes, MPA and LMAP, are in
the same LMM domain and securing the signaling is simplified.
7. Support for Heterogeneous Wireless Link Technologies
Proxy Mobile IPv6 is based on a heterogeneous mobility protocol.
8. Support for Unmodified Hosts
The Mobile Station should use DHCP to obtain an IP address and
network prefix and operate as a compliant IPv6 host. The MPA and
LMAP spoofs the MS to believe it is stationary, while allowing
movement within the LMM network.
9. Support for IPv4 and IPv6
Another advantage of leveraging a standard protocol is adapting
new ideas which goes through judicious debates in a public forum.
Supporting an IPv4 host with Proxy Mobile IPv6 involves adapting
the works in [14].
Gundavelli & Leung Expires May 12, 2006 [Page 6]
Internet-Draft LMM using MIPv6 November 2005
3.2. LMM Domain Architecture
The following illustration represents the LMM Domain model. A LMM
domain have the following properties:
a. A LMM domain is a topologically localized portion of the
network. Movement by the Mobile Station within a LMM domain will
get full mobility support and the mobility agents in the LMM
network exchange control messages for mobility without the need
for the MS to participate in the signaling.
b. As the Mobile Station move outside the boundary of the LMM
domain, global mobility is required. The Mobile Station can
function as a Mobile Node in accordance to Mobile IPv6 [2].
d. Each Mobile Station in its home LMM domain is anchored by a
LMAP. The security credentials and the policy data for it will be
typically managed by a AAA Server residing locally in that LMM
domain. When a Mobile Station moves out of its LMM domain, it may
be assigned a new LMAP in the visiting domain and that entity will
manage the mobility within the new LMM domain.
e. Each LMM domain will have the following functional elements,
LMAP, MPA, MS and AAA.
The following illustrates a LMM domain model:
Gundavelli & Leung Expires May 12, 2006 [Page 7]
Internet-Draft LMM using MIPv6 November 2005
|<-- Global Mobility -->|
|<- Local Mobility ->| |<- Local Mobility ->|
----------- -----------
/ \ / \
/ HA \ / HA \
| AAA | | AAA |
| LMAP | | LMAP |
| MPA | | MPA |
\ MS / \ MS /
\ /\ / \ /
----------- \ / -----------
LMM Domain#1 \ / LMM Domain#2
----------
| Internet | / \
---------- |
| |
| | Global Mobility
----------- |
/ \ |
/ HA \ |
| AAA | \ /
| LMAP |
| MPA |
\ MS /
\ /
-----------
LMM Domain#3
|<- Local Mobility ->|
Figure 1: LMM Domain Model
The following illustrates the network in a LMM domain:
Gundavelli & Leung Expires May 12, 2006 [Page 8]
Internet-Draft LMM using MIPv6 November 2005
+----+ +----+
|AAA |-----|DHCP|
+----+ | +----+
|
/ \
/ | \
/ | \
/ | \
/ | \
+----+ +----+ +----+
|LMAP| |LMAP| |LMAP|
+----+ +----+ +----+
/ \ / \ / \
/ \ / \ / \
+----+ +----+ +----+ +----+
|MPA | |MPA | |MPA | |MPA |
+----+ +----+ +----+ +----+
/ \ / \ / \ / \
/ \ / \ / \ / \
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
|BS| |BS| |BS| |BS| |BS| |BS| |BS| |BS|
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
| |
/:\ /:\
: :
: :
+--+ +--+
|MS| |MS|
+--+ +--+
Figure 2: Network in a LMM domain
3.3. New Functional Elements
The LMM scheme introduces two new functional elements, Local Mobility
Anchor Point (LMAP) and Mobility Proxy Agent (MPA). The following
section explains the scope and the role of these entities.
Local Mobility Anchor Point
LMAP functionally is a MIPv6 Home Agent as per the base Mobile
IPv6 specification [3]. It is the logical anchor point for the
Mobile Station. The Local Address of the Mobile Station belongs
to the Local Network Prefix owned by the LMAP. When the Mobile
Station is roaming in the LMM network, its LMAP intercepts all
Gundavelli & Leung Expires May 12, 2006 [Page 9]
Internet-Draft LMM using MIPv6 November 2005
packets destined to the Mobile Station and tunnels them to its
attached MPA. The packets from the MS are decapsulated and routed
normally.
Mobile Proxy Agent
The MPA is the Proxy Mobility Agent. This is the entity that
enables the Mobile Station on one of its link to use the assigned
Local Address and roam in the LMM network without having to
participate in mobility related signaling. It registers the
location of the MS to the LMAP and establishes a tunnel for
receiving packets sent to the Mobile Station. Packets from the MS
are put into the tunnel to the LMAP.
4. Message Formats
This section defines extensions to the MIPv6 Binding Update message.
4.1. Proxy Binding Update
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| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Proxy Binding Update Message
A new flag, the 'P' flag, is added to the Binding Update message.
The P flag indicates that the registration is a Proxy registration.
When a MPA sends a registration with the LMAP, the P flag MUST be set
to 1 indicate to the LMAP that this registration is a proxy
registration sent by a MPA on behalf of a Mobile Station.
Gundavelli & Leung Expires May 12, 2006 [Page 10]
Internet-Draft LMM using MIPv6 November 2005
4.2. Proxy Binding Acknowledgement
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|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Proxy Binding Acknowledgement Message
Proxy Registration Flag (P)
The Proxy Registration Flag is set to indicate that the LMAP that
processed the Proxy Binding Update supports Proxy Registration. It
is set to 1 only if the corresponding Binding Update had the Proxy
Registration Flag set to 1.
4.3. Binding Cache Confirmation Option
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A 8-bit field indicating the type of the mobility option.
Length
A 8-bit field indicating the length of the option. Set to 0.
The Binding Cache Confirmation option is included in the Proxy
Gundavelli & Leung Expires May 12, 2006 [Page 11]
Internet-Draft LMM using MIPv6 November 2005
Binding Update sent by the MPA when it does not know the Local
Address of the Mobile Station. Typically, this happens after network
access authentication informs that the Mobile Station arrived at the
MPA and triggers the registration.
5. Error Codes
5.1. Binding Acknowledgement Status Values
The following status code values are defined for using them in the
Binding Acknowledgement message when using LMM protocol.
140: Proxy Registration not supported
141: Binding Cache Entry missing
The value allocation for this usage needs to be approved by the IANA
and must be updated in the IANA registry.
6. Proxy Mobile IPv6
This section describes Local Mobility Management using Proxy Mobile
IPv6 support. In this model, a Mobile Station roaming in a LMM
network is not involved in any mobility related signaling.
The following sequence of steps happens when a Mobile Station
attaches to the network: network access authentication and
authorization, Router and Neighbor Discovery, and address
acquisition.
During network access authentication, the MPA obtains the Mobile
Station's profile from the AAA server. The attributes may include
the IP address and virtual MAC address of the LMAP, Local Network
Prefix (for dynamic LMAP resolution), assigned Local Address, and
DHCP server.
The MPA attempts to register the Mobile Station with its LMAP
immediately after successful network access authentication and when
the address acquisition is detected. A Mobile Station that boots up
on the network will be anchored after obtaining a Local Address.
Whereas a roaming Mobile Station's location is registered when
network access authentication completes. Mobility support for the
Mobile Station is achieved by the registration message exchange
between MPA and LMAP.
Gundavelli & Leung Expires May 12, 2006 [Page 12]
Internet-Draft LMM using MIPv6 November 2005
For Router and Neighbor Discovery, the Mobile Station is spoofed by
the MPA to be on the same link, which is the Local Network Prefix,
when attached to the LMM network even if the MPA changed during
handovers. The virtual LMAP MAC address is used by the MPA in Router
Advertisement and Neighbor Advertisement to the Mobile Station. The
Router Advertisement contains the Local Network Prefix.
There are several methods for the Mobile Station to obtain an IP
address: manual configuration, stateless auto-configuration, and
stateful DHCP. For DHCP, the MPA tags the DHCP Request with the
Local Network Prefix to ensure address allocation from the designated
address pool. When DHCP Reply is received, the MPA registers the
assigned IP address as the Local Address with the LMAP. For
stateless auto-configuration, the MPA registers the IP address when
Neighbor Solicit DAD message is received from the Mobile Station. In
addition, any packet from the Mobile Station can trigger a
registration with Local Address set to the Source IP address. This
would be the same case for manually configured MS. Typically, this
type of trust relationship with the Mobile Station (i.e. allowing MS
to dictate its Local Address) would not be permitted or only when
authorized by the AAA server.
When the Mobile Station obtains an IP address (used for all
communication sessions), the tunnel between MPA and LMAP is set up.
All packets sent to the Mobile Station from the corresponding nodes
will get intercepted at the LMAP and tunneled to the MPA, the MPA
will decapsulate the packet and forward to the MN. Any packets sent
to the corresponding node from the Mobile Station will get
intercepted at the MPA and will be tunneled to the LMAP, where the
packet is decapsulated the packet before being routed to the
corresponding node.
Gundavelli & Leung Expires May 12, 2006 [Page 13]
Internet-Draft LMM using MIPv6 November 2005
6.1. Network Access Authentication
MS MPA LMAP AAA
|Access | | |
|Initiation | | |
1)o---------->| | |
| | | |
| | AAA request |
2)| o---------------------->|
| | | | MS
3)| | | o Authenti
| | | | -cated
| | AAA reply |
4)| |<----------------------o
| | | |
|Access |MPA obtains| |
|Authenti o MN's | |
| -cation| profile | |
5)|<----------o | |
| | Proxy | |
| | Binding | |
| | Update | |
6)| o---------->| |
| | | |
| | | |
| | |Look up BCE|
7)| | o by NAI, |
| | | success |
| | | if found |
| | Proxy | |
| | Binding | |
| | Ack | |
8)| o<----------| |
| | | |
| |Setup | |
| |LMAP-MPA | |
9)| o tunnel | |
| | if success| |
| | code in BA| |
Figure 6: Network Access Procedure Control Flows
Gundavelli & Leung Expires May 12, 2006 [Page 14]
Internet-Draft LMM using MIPv6 November 2005
The network access authentication and authorization procedure permits
a valid Mobile Station connectivity in the network. Upon successful
authentication by the AAA server, the MPA retrieves the MS's profile
containing NAI and the assigned LMAP (steps #1 through #5). It's
possible that such information is obtained by some other methods, but
that is out of scope of this document. Note that the LMAP is on the
Local Network Prefix, so Once the NAI of the Mobile Station and
assigned LMAP are known, the MPA sends a Proxy Binding Update to the
LMAP (in step #6). The message includes the Mobile Node Identifier
Option [11] to deliver the NAI information to the LMAP. If the Local
Address or Local Network Prefix is assigned by the AAA server, the
Assigned Home Address Option [10]is also included in the Proxy
Binding Update. Otherwise, the Binding Cache Confirmation Option is
appended in the message to request the LMAP to check if BCE exists
(indexed by the NAI) for the Mobile Station (in step #7). In the
case of Home Address Option, the LMAP creates or updates the BCE and
sets up tunnel to the MPA for the Mobile Station before acknowledging
the MPA. When Binding Cache Confirmation Option is received, the
LMAP checks if the BCE exists or not. If the BCE is found, the LMAP
adds the Assigned Home Address Option to the successful Proxy Binding
Acknowledgement. Otherwise, the error code "Binding Cache Entry
missing" is set in the reply message. The Proxy Binding
Acknowledgement is sent to the MPA (in step #8). When MPA receives a
successful reply, the tunnel and routing is set up for the Mobile
Station (in step #9). Note when LMAP is on the Local Network Prefix,
so the MPA is aware of the Local Network Prefix for the Mobile
Station to partake in the Router and Neighbor Discovery process.
6.2. Router and Neighbor Discovery with Local Network Spoofing
Gundavelli & Leung Expires May 12, 2006 [Page 15]
Internet-Draft LMM using MIPv6 November 2005
MS MPA LMAP AAA
|LLA DAD | | |
1)o---------->| | |
| | | |
2)| o Normal DAD| |
| | operation | |
| | | |
| | If dup | |
| | addr, send| |
| | NA | |
3)|<----------o | |
| | | |
|RS | | |
4)o---------->| | |
| | | |
| RA | | |
5)|<----------o | |
Figure 7: MPA Behavior in Router and Neighbor Discovery
Router and Neighbor Discovery between the Mobile Station and MPA is
different than conventional IPv6 because the MPA is spoofing as the
LMAP is advertising the Local Network Prefix directly to the Mobile
Station. When MS sends Neighbor Solicitation for Link-Local Address
Duplicate Address Detection (DAD) [RFC 2462], MPA performs normal DAD
functions and responds accordingly (in steps #1 through #3). When
duplicate addresses are detected on the link, recovery mechanisms are
specified in RFC 2462. The Mobile Station sends a Router
Solicitation to MPA (in step #4). The MPA sets the link prefix
information in the advertisement message to the Local Network Prefix
for the Mobile Station. The Router Advertisement contains the Prefix
Information option with the "on-link" (L) flag set to zero to inform
the Mobile Station to send to packets to the default router, which is
the LMAP [RFC 2461]. The Router Advertisement is sent directly to
the MAC address of the Mobile Station (in step #5). The Mobile
Station sends Neighbor Solicitation to learn the MAC address of the
default gateway (i.e. LMAP). MPA sends Neighbor Advertisement with
the virtual MAC address of the LMAP which it uses to receive packets
from MS.
6.3. Address Configuration
The LMM scheme allows the Mobile Station to operate as a normal IPv6
Gundavelli & Leung Expires May 12, 2006 [Page 16]
Internet-Draft LMM using MIPv6 November 2005
host using the standard IPv6 address configuration schemes.
From the Mobile Station's perspective, there are three methods to
obtain an IP address: manual configuration, DHCP, or stateless auto-
configuration.
1. Manual Configuration:
In this case, the Local Address, Local Network Prefix, and the LMAP
address are manually configured on the Mobile Station as the IP
address, Link Prefix, and Default Gateway, respectively. The Mobile
Station does not depend on the Router Advertisements or on DHCP for
address configuration. The static IP address of the Mobile Station
is used for network connectivity. The configuration must match the
parameters assigned to the Mobile Station in the LMM network for
mobility support. This method is detected by the network in the same
manner as the stateless auto-configuration.
2. Stateless Address Auto Configuration:
Upon receiving a Router Advertisement with the "Managed" bit not set,
the Mobile Station (operating as a normal IPv6 host) performs
Stateless Auto-Configuration to obtain the host configuration. The
LMM network detects the IP address of the Mobile Station from DAD or
IP packets received from the MS. Figure 8 illustrates this scenario.
3. Using DHCPv6 for Address Configuration:
Upon receiving a Router Advertisement with the "Managed" bit set, the
Mobile Station (operating as a normal IPv6 host) uses DHCP to obtain
the host configuration. The LMM network assigns the IP address using
AAA server, DHCP server, or LMAP. When Local Address is assigned by
a non-DHCP server, renewal still requires DHCP server to interact
with the DHCP client in the MS.
Gundavelli & Leung Expires May 12, 2006 [Page 17]
Internet-Draft LMM using MIPv6 November 2005
MS MPA LMAP DHCP Server
|LoA DAD or | | |
|IP packet | | |
1)o---------->| | |
| | | |
| | Proxy | |
| | Binding | |
| | Update | |
2)| o---------->| |
| | | |
| | | |
| | | Create BCE|
3)| | o for MS |
| | Proxy | |
| | Binding | |
| | Ack | |
4)| o<----------| |
Figure 8: Stateless Auto-Configuration
The Mobile Station sends Neighbor Solicitation for Local Address DAD
or any other IP packet will trigger MPA to learn and register the
MS's Local Address (in step #1). MPA sends a Proxy Binding Update
with Assigned Home Address Option and Mobile Node Identifier Option
(in step #2). The former option contains the Local Address and the
latter option contains the NAI. LMAP creates the BCE and sets up
tunnel for the MS (in step #3). The Proxy Binding Acknowledgement is
sent to the MPA (in step #4).
Gundavelli & Leung Expires May 12, 2006 [Page 18]
Internet-Draft LMM using MIPv6 November 2005
MS MPA LMAP DHCP Server
|DHCP Req | | |
1)o---------->| | |
| | | |
| |Normal | |
| |Relay Agent| |
2)| o---------------------->|
| | | DHCP Reply|
3)| |<----------------------o
| | | |
4)|<----------o | |
| | | |
| | Proxy | |
| | Binding | |
| | Update | |
5)| o---------->| |
| | | |
| | | |
| | | Create BCE|
6)| | o for MS |
| | Proxy | |
| | Binding | |
| | Ack | |
7)| o<----------| |
Figure 9: Stateful DHCP
The Mobile Station initiates the DHCP process after link comes up.
The MPA operates as a normal DHCP Relay Agent and forwards requests
from the Mobile Station to the DHCP Server. The DHCP Relay-Forward
message is tagged with Local Network Prefix information for the DHCP
Server to assign the IP address from the designated address pool.
The DHCP server sends DHCP Reply to the MPA, which forwards to the MS
(in steps #1 through #4). When MPA learns the assigned IP address,
it sends a Proxy Binding Update with Assigned Home Address Option and
Mobile Node Identifier Option (in step #5). The former option
contains the Local Address and the latter option contains the NAI.
LMAP creates the BCE and sets up tunnel for the MS (in step #6). The
Proxy Binding Acknowledgement is sent to the MPA (in step #7).
Gundavelli & Leung Expires May 12, 2006 [Page 19]
Internet-Draft LMM using MIPv6 November 2005
6.4. Resource Cleanup
MS New MPA LMAP Previous MPA
| | Proxy | |
| | Binding | |
| | Update | |
1)| o---------->| |
| | | |
| | | Update |
| | | existing |
2)| | o BCE for MS|
| | | |
| | | Proxy |
| | | Binding |
| | | Revocation|
3)| | o---------->|
| | | |
4)| | | o Remove visitor
| | | | entry for MS
| | | |
| | | | Proxy Binding
| | | | Revoc Ack
5)| | |<----------o
| | | |
| | Proxy | |
| | Binding | |
| | Ack | |
6)| o<----------o |
Figure 10: Binding Revocation for Previous MPA
MPA which no longer serve the Mobile Station needs to remove any
associated mobility states and relinquish resources which are no
longer needed.
When LMAP receives a Proxy Binding Update for a Mobile Station with
an existing BCE, a Registration Revocation [13] is sent to the
previous MPA (in steps #1 through #3). The MPA removes the visitor
entry for the Mobile Station before sending acknowledgement to the
LMAP (in steps #4 and #5). In parallel, the LMAP sends the Proxy
Binding Acknowledgement to the new MAP (in step #6). At the end of
sequence of events, only states in the LMM network are in the MPA
Gundavelli & Leung Expires May 12, 2006 [Page 20]
Internet-Draft LMM using MIPv6 November 2005
where MS is attached and the LMAP.
7. Mobility Proxy Agent Operation
The MPA function has two parts. For data path, MPA provides the same
role as a Foreign Agent in Mobile IPv4 [RFC 3344]. It encapsulates
and decapsulates packets to and from the LMAP, respectively. The
other function of this entity is to signal to the LMAP to set up the
tunnel for the data path when the Mobile Station is visiting.
When the mobile station using a wireless link attaches to a LMM
network, it attempts to authenticate to the network using the
enforced Layer-2 authentication protocol and the MPA on the link on
detecting this new mobile station will trigger the Layer-3 mobility
signaling. The MPA on the link will identify the mobile station and
will download its profile from the Policy Enforcement Point. The
profile typically will contain the contain the Local Network Prefix,
Local Address and the supported IPv6 Address Configuration mode and
the Default Router on its link.
Following is the typical configuration that is maintained by the AAA
server for each Mobile Station:
1. NAI
2. Authentication Credentials
3. LMAP Address
4. Local Network Prefix (Optional)
5. Local Address (Optional)
6. Default Gateway Address (Optional)
Once the MPA downloads the Mobile Station's profile, it will respond
to the Router Solicitation messages received from the Mobile Station
with a Router Advertisement reflecting the Mobile Station's home link
and thus making the Mobile Station to believe it's on the home link.
7.1. Conceptual Data Structures at the MPA
Each MPA must maintain a Visitor List. Each entry in the list
represents an attached Mobile Station and its parameters:
Gundavelli & Leung Expires May 12, 2006 [Page 21]
Internet-Draft LMM using MIPv6 November 2005
o The NAI of the Mobile Station. This is obtained from the network
access authentication messages. The NAI is the identifier that
will be used by the MPA to download the MS's profile.
o MAC Address of the Mobile Station, obtained by the MPA during the
network access authentication procedure.
o Local Address of the Mobile Station, obtained by the MS using
DHCP. However, the network can assign the Local Address using one
of the following methods: downloaded from the AAA server along
with other attributes, assigned by the LMAP in the registration
process, and learned from DAD sent by the Mobile Station.
o Local Network Prefix of the Mobile Station obtained from either
the AAA or LMAP.
o IP address and virtual MAC address of the LMAP obtained from the
AAA as part of the profile download.
o Source address of the tunnel between the MPA and LMAP. This is
either the Source Address field in the IPv6 header or by the
Alternate Care-of Address option, if present in the Proxy Binding
Update.
o Destination address of the tunnel between the MPA and LMAP. This
is the Destination Address field in the IPv6 header of the Proxy
Binding Update.
o Registration lifetime that is established with the Mobile
Station's LMAP.
o DHCP Server address assigned by the AAA server. MPA sends DHCP
messages to this DHCP Server when the Mobile Station performs
either stateless or stateful DHCP procedure.
7.2. Mobility Signaling for Mobile Station
After network access authentication, MPA sends Proxy Binding Update
to the LMAP.
The MPA uses the Local Network Prefix for the Mobile Station to
advertise the link prefix information to the Mobile Station. The
Router Advertisement contains the Prefix Information option with the
"on-link" (L) flag set to zero to inform the Mobile Station to send
packets to the default router, which is the LMAP [RFC 2461].
Gundavelli & Leung Expires May 12, 2006 [Page 22]
Internet-Draft LMM using MIPv6 November 2005
7.3. Establishment of Bi-Directional Tunnel
After receiving a successful Binding Acknowledgement for the Proxy
Binding Update, the MPA sets up a tunnel to the Mobile Station's
LMAP.
The bi-directional tunnel between the MPA and the LMAP allows packets
to flow in both directions, while the mobile station is connected to
its visited link. The tunnel endpoints are the LMAP and the MPA.
All IPv6 traffic to and from the Mobile Station is sent through this
bi-directional tunnel.
While the MPA is serving a Mobile Station, it MUST be able to
intercept all packets sent from the Mobile Station and forward them
out the MPA-LMAP tunnel created for supporting that Mobile Station.
Any packets received on the tunnel from LMAP, the MPA decapsulates
before forwarding to the Mobile Station on its link.
8. Mobile Station Operation
As per this specification, a mobile station present in a LMM domain
would function as a normal IPv6 host. The required behavior of the
node will be consistent with the base IPv6 specification [1]. The
mobile station in a LMM domain will have the ability to retain its
IPv6 address as it moves from one point of network attachment to the
other with out ever requiring it to participate in any mobility
related signaling.
The mobile station when boots up for the first time in a LMM domain,
would be assigned a Local Home Network prefix and can obtain an IPv6
address from that Prefix in one or more ways. Once the mobile
station obtains an IPv6 address, it will have the ability to move
with in this LMM network and with out having to obtain a new address.
The LMM network entities will ensure the mobile station gets seamless
mobility with in the boundaries of this LMM network. However, the
mobile station when roaming across LMM domains MAY use Mobile IPv6
signaling, if it requires IPv6 mobility.
As the mobile station roams with in the LMM network, moving from one
link to the other, it always detects its local home network. The MPA
on the attached link emulates the home link behavior for the mobile
station. It makes the mobile station believe its on its home link.
The Router Solicitation messages will result in a Router
Advertisement with its home prefix, default router and other
Gundavelli & Leung Expires May 12, 2006 [Page 23]
Internet-Draft LMM using MIPv6 November 2005
configuration parameters that the LMM entities make sure remain
consistent with the home link properties. If the node address
configuration policy on the mobile station's home link requires the
mobile station to depend on DHCP for obtaining address configuration,
LMM entities will ensure, the mobile station using DHCP protocol will
obtain its assigned local address. Further, the mobile station will
be able to use the Neighbor discovery protocol as it would on its
home link.
8.1. Booting up in a LMM Domain
When the Mobile Station enters a LMM domain for the first time and
attaches to a link on the MPA, it will present its identity in the
form of NAI to the network as part of the network access
authentication process. After a succesful authentication, the mobile
station will send a Router Solicitation message. The MPA on the link
will respond to the Router Solicitation message with a Router
Advertisement. The Router Advertisement will have the mobile
station's home prefix, default router and other configuration
parameters. The address configuration parameters such as Managed
Address Configuration, Stateful Configuration flag values will be
consistent with the home link policy.
If the Router Advertisement has the Managed Address Configuration
flag set, the mobile station, as it would normally do, will send a
DHCP Request and again the LMM entities will ensure, the mobile
station gets its local address as a lease from the DHCP server.
If the Router Advertisement does not have the Managed Address
Configuration flag set, the mobile station can autoconfigure itself
by appending its link-layer address (EUI-64 format) to the advertised
local home network prefix.
Once the address configuration is complete, the Mobile Station will
always be able to use that IP address anywhere in that LMM domain.
Further, the Mobile Station may get the same Local Address even after
a reboot. In the current context, usage of the word "Local Address"
is not related to "Link-Local Address", but instead refers to an
invariant IPv6 address that the Mobile Station owns throughout its
presence in the LMM domain.
8.2. Moving to a New MPA
When a Mobile Station moves to a new MPA from another MPA, the
following occurs:
The Mobile Station will perform a network access authentication with
Gundavelli & Leung Expires May 12, 2006 [Page 24]
Internet-Draft LMM using MIPv6 November 2005
the attached MPA. If the authentication fails, the Mobile Station
will not be able to use the link. After a succesful authentication,
the MPA will have the identifier and the other profile data of the
Mobile Station.
Once the network access authentication process is complete, the
Mobile Station sends a multicast Router Solicitation message to the
All-Routers multicast address on that new link, either using the
Link-Local address or the using the unspecified address (::) as the
Source Address in the IPv6 header.
The Access Router with the MPA function on receiving this Router
Solicitation message will respond with a Router Advertisement. The
reply is sent to the unicast Link-Local Address or All-Nodes
Multicast Address depending if the Source Address is Link-Local
Address or unspecified address, respectively. The Destination
Address is in compliance to IPv6. However, the Destination MAC
address in the Router Advertisement MUST always be set to the Source
MAC address of the Router Solicitation.
If the Router Advertisement has the Managed Address Configuration
flag set, the mobile station, as it would normally do, will send a
DHCP Request and again the LMM entities will ensure, the mobile
station gets its local address as a lease from the DHCP server.
If the Router Advertisement does not have the Managed Address
Configuration flag set, the mobile station can autoconfigure itself
by appending its link-layer address (EUI-64 format) to the advertised
local home network prefix.
8.3. Packet forwarding
All packets that are be sent from the Mobile Station to the
corresponding node will be sent as normal IPv6 packets setting the
Source Address of the IPv6 header to the Local Address and the
Destination Address to the corresponding node's IP address. The
default gateway for the Mobile Station will always be its LMAP. The
Neighbor Cache Entry for LMAP address is a pseudo LMAP MAC address.
Similarly, all packets sent to the Mobile Node's Local Address by the
corresponding node will be received by the Mobile Station in the
original form (without any tunneling overhead) on its link.
No special operation is required by the Mobile Station to either send
or receive packets.
Gundavelli & Leung Expires May 12, 2006 [Page 25]
Internet-Draft LMM using MIPv6 November 2005
8.4. Moving to a New LMM Domain
The LMM scheme defined in this document, provides mobility support to
the Mobile Station within that LMM domain. Once the Mobile Station
obtains an assigned Local Address, it can continue to use the same
address roaming between MPAs in the network with its LMAP providing
the topological anchor point for that address. However, the Mobile
Station while roaming across LMM domains is required to have the
Mobile IPv6 stack and operate as a normal MIPv6 mobile node to
achieve mobility across LMM domains.
9. LMAP Operation
LMAP is functionally a MIPv6 Home Agent. It is the topological
anchor point for the Mobile Station's Local Network Prefix. When a
Mobile Station enters a LMM domain for the first time, a LMAP and a
Local Network Prefix gets assigned to that Mobile Station. The
following section explains the LMAP function:
9.1. Processing Proxy Binding Update
Upon the receipt of a Proxy Binding Update from a MPA, the LMAP
checks if the Binding Cache Confirmation Option is included. If so,
LMAP looks up the BCE indexed by the NAI. If BCE exists, LMAP sends
a Proxy Binding Acknowledgement with Assigned Home Address Option.
The Local Address in the BCE is set in the appended option. The
Local Home Prefix is in the prefix length field of the option. In
this case, LMAP updates the Care-of Address in the BCE to the MPA
that sent the PBU. If there is no BCE for the MS, then LMAP sends
PBA with error code "Binding Cache Entry missing" in the message.
9.2. Packet interceptions
When the LMAP intercepts a packet sent to the mobile station's home
address, it tunnels the packet to the attached MPA of the mobile
station. The encapsulated packet will contain the following.
Outer IPv6 Header:
Gundavelli & Leung Expires May 12, 2006 [Page 26]
Internet-Draft LMM using MIPv6 November 2005
The source address is the LMAP's address and the destination
address is the Mobile Station's Care-of Address (i.e. the MPA's
address).
Inner IPv6 Header:
The source address is the corresponding node's address and the
destination address is the Mobile Station's Local Address.
10. IANA Considerations
This document defines a new Mobility Header Option, the Binding Cache
Confirmation Option. The type value for this option MUST be assigned
from the same space used by the mobility options defined in [1].
This document defines a new flag (P) to the Binding Update and
Binding Acknowledges messages specified in [2].
This document also defines new Binding Acknowledgement status values
as described in Section 4.5. The status values MUST be assigned from
the same space used for Binding Acknowledgement status values in [2].
11. Security Considerations
This document introduces new mobility entities, LMAP and MPA. These
are the entities that are involved in the signaling for providing
Layer-3 mobility to a Mobile Station. The protocol requires these
entities to have established security associations for securing the
signaling traffic. The messages MUST be protected by IPSec or using
an Authentication Option [12].
12. Acknowledgements
13. Normative References
[1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
Gundavelli & Leung Expires May 12, 2006 [Page 27]
Internet-Draft LMM using MIPv6 November 2005
[3] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents",
RFC 3776, June 2004.
[4] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G.,
Liebsch, M., "Problem Statement for IP Local Mobility".
draft-kempf-netlmm-nohost-ps-00, June 2005.
[5] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G.,
Liebsch, M., "Requirements and Gap Analysis for IP Local Mobility".
draft-kempf-netlmm-nohost-req-00, June 2005.
[6] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification",
RFC 2463, December 1998.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[9] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998.
[10] Devarapalli, V. et. al., "Mobile IPv6 Bootstrapping for the
Authentication Option Protocol",
draft-devarapalli-mip6-authprotocol-bootstrap-00.txt, November 2005.
[11] Patel, A. et. al., "Mobile Node Identifier Option for MIPv6",
draft-ietf-mip6-mn-ident-option-03, September 2005.
[12] Patel, A. et. al., "Authentication Protocol for Mobile IPv6",
draft-ietf-mip6-auth-protocol-07.txt, September 2005.
[13] Haley, B., Gundavelli, S., "Mobility Header Signaling Message",
draft-haley-mip6-mh-signaling-01.txt, October 2005.
[14] Soliman, S., Tsirtsis, G., "Dual Stack Mobile IPv6",
draft-soliman-v4v6-mipv4-02.txt, July 2005.
[15] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
2002.
Gundavelli & Leung Expires May 12, 2006 [Page 28]
Internet-Draft LMM using MIPv6 November 2005
Authors' Addresses
Sri Gundavelli
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
US
Email: sgundave@cisco.com
Kent Leung
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
US
Email: kleung@cisco.com
Gundavelli & Leung Expires May 12, 2006 [Page 29]
Internet-Draft LMM using MIPv6 November 2005
Intellectual Property Statement
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 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 Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gundavelli & Leung Expires May 12, 2006 [Page 30]
