NETEXT Working Group V. Devarapalli
Internet-Draft WiChorus
Intended status: Standards Track N. Kant
Expires: September 4, 2009 H. Lim
Stoke
C. Vogt
Ericsson
March 3, 2009
Multiple Interface Support with Proxy Mobile IPv6
draft-devarapalli-netext-multi-interface-support-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to format it
for publication as an RFC or to translate it into languages other
than English.
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 September 4, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
Devarapalli, et al. Expires September 4, 2009 [Page 1]
Internet-Draft PMIPv6 Multiple Interface Support March 2009
and restrictions with respect to this document.
Abstract
Proxy Mobile IPv6 enables network-based mobility for a regular IPv6
mobile node with no mobility management protocol. It makes it appear
to the mobile node that its IP address does not change as the mobile
node moves across the Proxy Mobile IPv6 domain. There have been some
issues identified with supporting a host with multiple interfaces
attaching to the Proxy Mobile IPv6 domain. This document describes
and analyzes some of the scenarios associated with this. It also
describes the requirements for a handover across interfaces using
Proxy Mobile IPv6.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Multiple Interface Scenarios . . . . . . . . . . . . . . . . . 4
3.1. Unique Prefix per Interface . . . . . . . . . . . . . . . 4
3.2. Unique Address per Interface . . . . . . . . . . . . . . . 5
3.3. Shared Address across Interfaces . . . . . . . . . . . . . 6
4. Handovers across Interfaces . . . . . . . . . . . . . . . . . 8
4.1. Requirements for a PMIPv6 Handover across Interfaces . . . 8
4.1.1. Removal of IP Address/Prefix from Old Interface . . . 8
4.1.2. Configuration of Same IP Address/Prefix on New
Interface . . . . . . . . . . . . . . . . . . . . . . 9
4.1.3. Update of Active Socket Structures . . . . . . . . . . 9
4.2. Handover across Interfaces using a PMIPv6 virtual
interface . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Inter-Access Technology Handovers . . . . . . . . . . . . 9
4.4. Mobile node with three or more interfaces . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Devarapalli, et al. Expires September 4, 2009 [Page 2]
Internet-Draft PMIPv6 Multiple Interface Support March 2009
1. Introduction
Proxy Mobile IPv6 [2] provides network-based mobility for a regular
IPv6 mobile node with no mobility management protocol. It is quite
straight forward to provide mobility for a mobile node with one
interface. There are some issues identified with supporting a host
with multiple interfaces attaching to the Proxy Mobile IPv6 domain.
The multiple interfaces on the mobile node could be of the same or
different access technology types. If the mobile node has multiple
interfaces attached to the Proxy Mobile IPv6 domain, and wishes to
use both interfaces simultaneously, the LMA and the MAGs in the Proxy
Mobile IPv6 domain must allow this.
The mobile node may also decide to handoff sessions from one
interface to another. The two interfaces involved in the handover
could be of the same or different access technology types.
In some cases, the mobile node may be assigned the same prefix across
two interfaces when both interfaces are attached to the Proxy Mobile
IPv6 domain. The mobile node may be a regular IPv6 host which cannot
handle the same prefix across two different interfaces. Some mobile
nodes have multi-homing support in the sense that they can connect to
the same subnet via two interfaces and still able to send and receive
packets on both interfaces.
This document analyzes three different scenarios with respect to a
mobile node with multiple interfaces attaching to a Proxy Mobile IPv6
domain.
o Assigning a unique prefix per interface of the mobile node.
o Assigning the same prefix across interfaces but a unique address
per interface.
o Shared address across interfaces.
In all three scenarios the mobile node is able to use the multiple
interfaces simultaneously to send and receive packets.
This document also analyzes the requirements on a IPv6 host to
support a handover across interfaces when Proxy Mobile IPv6 is used
in Section 4.1.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
Devarapalli, et al. Expires September 4, 2009 [Page 3]
Internet-Draft PMIPv6 Multiple Interface Support March 2009
3. Multiple Interface Scenarios
Three different scenarios are considered in this document. The
following sections describe and analyze the three scenarios.
3.1. Unique Prefix per Interface
In this scenario, each interface on the mobile node is assigned a
unique prefix. The LMA maintains multiple binding cache entries, one
entry per interface on the mobile node. The binding cache entries
may contain the Layer 2 interface identifier and the access
technology type of the corresponding interface on the mobile node.
The LMA also maintains two separate routes for prefix1 and prefix2.
LMA Binding Cache
+----+ -----------------
|LMA | MN:if1 [prefix1] --> MAG1
+----+ MN:if2 [prefix2] --> MAG2
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| |
| |
| if1 if2 |
+------[MN]------+
Figure 1: Unique Prefix per Interface
The mobile node is able to use both interfaces simultaneously for
sending and receiving packets. Since the LMA maintains separate
route entries for prefix1 and prefix2, it encapsulates and forwards
the packets via the appropriate MAG.
When the mobile node moves and attaches to another MAG in the same
Proxy Mobile IPv6 domain, session continuity is maintained by
assigning the same prefix to the interface. If the mobile node moves
and attaches to MAG3 with if1, the MAG3 sends a Proxy Binding Update
message to the LMA with the access technology type and interface
identifier of if1. The LMA checks if there is an existing binding
cache entry for the mobile node for if1. If there is an existing
Devarapalli, et al. Expires September 4, 2009 [Page 4]
Internet-Draft PMIPv6 Multiple Interface Support March 2009
binding cache entry, the LMA assigns the same prefix previously
assigned and responds to MAG3.
If there is no L2 interface identifier that MAG3 could identify for
if1 and did not include the interface identifier in the Proxy Binding
Update, then the LMA does not know if this is a handover for if1 or
if the mobile node is attaching via a new interface to MAG3. The
LMA's decision is then based on what the Handoff Indicator field in
the Handoff Indicator option is set to. If MAG3 knows that the
mobile node was attached to another MAG in the same Proxy Mobile IPv6
domain using if1, then it must indicate to the LMA that it is a
handover. This would ensure that the mobile node sees the same
prefix for if1. Otherwise the mobile node ends up with a new prefix
for if1.
The Proxy Mobile IPv6 specification [2] does not specify any
mechanism for MAG3 to figure out if the mobile node is performing a
handover for if1 or if it is attaching to the Proxy Mobile IPv6
domain for the first time via if1. One option is for MAG3 to obtain
this information via context transfer from MAG1. This solution
requires a context transfer interface between MAG1 and MAG3. Another
option is for MAG3 to be told by the AAA infrastructure as part of
access authentication that the mobile node was previously attached to
the Proxy Mobile IPv6 domain via if1. However, this solution may not
work in case the AAA infrastructure does not store interface related
information or if the AAA infrastructure is not being used. One
solution that may work in most cases is for the mobile node to
indicate to MAG3 that it already has sessions on top of the prefix
assigned to if1 and it is performing a handover. The mobile node
conveys this information as part of Layer 2 setup. When MAG3 gets
this information, it sets the Handoff Indicator field in the Handoff
Indicator option to indicate a handover for if1.
Section 4 discusses handovers between interfaces using Proxy Mobile
IPv6 in more detail.
3.2. Unique Address per Interface
In this scenario, the mobile node is assigned the same prefix across
multiple interfaces, but with a unique address per interface. The
LMA maintains separate binding cache entries per address of the
mobile node. The LMA may also maintain a single binding cache entry,
but must have separate host route entries per address assigned to the
mobile node. This scenario illustrated in Figure 2 creates a multi-
homing scenario where the mobile node has connectivity via two
interfaces to the same subnet.
Devarapalli, et al. Expires September 4, 2009 [Page 5]
Internet-Draft PMIPv6 Multiple Interface Support March 2009
LMA Binding Cache
+----+ -----------------
|LMA | MN:if1 [addr1] --> MAG1
+----+ MN:if2 [addr2] --> MAG2
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| |
| |
| if1 if2 |
+------[MN]------+
Figure 2: Unique Address per Interface
The mobile node is able to use both interfaces simultaneously for
sending and receiving packets. Since the LMA maintains separate host
route entries for addr1 and addr2, it encapsulates and forwards the
packets via the appropriate MAG.
This scenario however creates a multi-link subnet since the same
prefix is advertised over two different point-to-point links.
Neighbor discovery is not run across the two point-to-point links
even though the same prefix is used across the links. Please refer
to [5] for more information on issues regarding multi-link subnets.
3.3. Shared Address across Interfaces
In this scenario, the mobile node is assigned the same address across
multiple interfaces. This scenario enables a mobile node to use
different links, but make only one IP address visible to the
applications. The mobile node can send and receive packets for one
particular application flow over if1 and for another application flow
over if2. This scenario also enables a mobile node to combine two
low bandwidth links into a high bandwidth link. Figure 3 illustrates
this scenario.
Devarapalli, et al. Expires September 4, 2009 [Page 6]
Internet-Draft PMIPv6 Multiple Interface Support March 2009
LMA State
+----+ ---------
|LMA | MN:if1 [addr, flow1] --> MAG1
+----+ MN:if2 [addr, flow2] --> MAG2
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| |
| |
| if1 if2 |
+------[MN]------+
Figure 3: Shared Address across Interfaces
The LMA maintains only one binding cache entry per mobile node in
this scenario. However, the LMA maintains flow filters that indicate
routing to a particular MAG. For example, lets assume that the
mobile node has two separate flows, flow1 and flow2 and wants to run
flow1 over if1 and flow2 over if2. When the LMA receives a packet
for the mobile node, it checks the flow filters stored in the binding
cache entry. If the packets match filter1, the LMA tunnels the
packets to MAG1.
For this scenario to work, the mobile node must be able to indicate
to the attached MAG which flow will be sent over the attachment to
the MAG. It may do this by indicating the service identifier during
the layer 2 attachment to the MAG. The service identifier is
described in [4]. The MAG, in turn must include the flow information
in the Proxy Binding Update sent to the LMA. The MAG may use the
Service Selection option [4] in the Proxy Binding Update to indicate
the flow information. The MAG may also construct a flow filter and
convey the information in the Proxy Binding Update. See [3] for more
information on carrying flow filters in the proxy binding update.
The LMA processes the Proxy Binding Update from the MAG and creates a
filter based on the flow information. The flow filters may be stored
in the binding cache entry for the mobile node.
Devarapalli, et al. Expires September 4, 2009 [Page 7]
Internet-Draft PMIPv6 Multiple Interface Support March 2009
4. Handovers across Interfaces
The followings describe handovers across multiple interfaces on a
mobile node using Proxy Mobile IPv6.
4.1. Requirements for a PMIPv6 Handover across Interfaces
Using Proxy Mobile IPv6 for handovers across interfaces requires the
following at the minimum on the mobile node.
o Removal of the IP address/prefix from the old interface.
o Configuration of the same IP address/prefix on the new interface.
o Update of active socket structures to the new interface.
The following describes the requirements for a handover across
interface in more detail.
4.1.1. Removal of IP Address/Prefix from Old Interface
An IP address can be removed from the old interface through a tear-
down of the link-layer connection, provided the IP address was auto-
configured. Standard host stack implementations remove auto-
configured IP addresses from interfaces that have lost link-layer
connectivity. The advantage of this mechanism is that it is network-
controlled and does not require special host functionality. A
disadvantage of the mechanism is its coarse granularity: A link-layer
connectivity tear-down leads to the removal of all IP addresses on an
interface. So if an interface has multiple IP addresses, all of them
are removed, yet a handover may be desired for only one of them.
Link-layer connectivity tear-down is the only means by which a
network can control the removal of an IP address from an old
interface. Standard host stack implementations generally do not
accept IP layer control messages as a trigger for IP address removal.
For example, zero-lifetime advertisements for an IP address prefix in
Router Advertisement messages [6] are ignored in an effort to protect
against denial-of-service attacks.
Alternative mechanisms to remove an IP address from the old interface
therefore require new functionality on mobile nodes. The handover
may be indicated by the network, such as through a zero-lifetime
advertisement for an IP address prefix in Router Advertisement
messages. But it is the mobile node which must correctly interpret
such indication and remove the corresponding IP address.
Devarapalli, et al. Expires September 4, 2009 [Page 8]
Internet-Draft PMIPv6 Multiple Interface Support March 2009
4.1.2. Configuration of Same IP Address/Prefix on New Interface
A successful handover across interfaces requires a mobile node to
configure the new interface with the same IP address that was
previously used on the old interface. The standard mechanism for
autonomous address auto-configuration in IPv6, Stateless Address
Autoconfiguration [7], does not support this. It derives IP
addresses from the respective interface identifiers, and thus
generates different IP addresses on different interfaces.
Configuration of the same IP address on a new interface therefore
requires either network-controlled IP address configuration through
DHCPv6, L2 address assignment mechanisms or new functionality on the
mobile nodes.
4.1.3. Update of Active Socket Structures
Typically, sockets structures are opened based on the address
assigned to an interface. As long as the address is available on one
of the interfaces on the mobile node, the active sockets should not
get affected. However, many implementations today include a pointer
to the interface in socket structures. This makes handovers between
different interfaces impossible. Handovers across interfaces may
therefore require modifications to such implementations to make
socket structures interface-independent.
4.2. Handover across Interfaces using a PMIPv6 virtual interface
The mobile node may also implement a virtual interface that hides the
multiple physical interfaces involved in the handover. The address
that the mobile node configures, when it is attached to the Proxy
Mobile IPv6 domain, is assigned to the virtual interface. Only the
virtual interface and the address configured on the virtual interface
are visible to the applications on the mobile node.
If only one interface is active at a time, then the mobile node maps
the virtual interface to the active physical interface. When a
handover happens, the mobile node maps the virtual interface to the
new active physical interface. The implementation of this virtual
interface can be done in a manner similar to the Linux Port Bonding
[8]. The actual implementation details are out of scope of this
document.
4.3. Inter-Access Technology Handovers
This section considers a handover scenario where the mobile node
performs a handover between interfaces that belong to different
access technologies.
Devarapalli, et al. Expires September 4, 2009 [Page 9]
Internet-Draft PMIPv6 Multiple Interface Support March 2009
The mobile node is initially attached to the Proxy Mobile IPv6 domain
via MAG1 using if1 as show in Figure 4.
LMA Binding Cache
+----+ -----------------
|LMA | MN:if1 [prefix1] --> MAG1
+----+
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
|
|
| if1 if2
+------[MN]------
Figure 4: Mobile Node attached via if1
The mobile node moves and attaches to the same Proxy Mobile IPv6
domain via MAG2 using if2. The mobile node may not have connectivity
on if1 anymore. The LMA assigns the same prefix for if2 and updates
its binding cache entry. This is illustrated in Figure 5.
Devarapalli, et al. Expires September 4, 2009 [Page 10]
Internet-Draft PMIPv6 Multiple Interface Support March 2009
LMA Binding Cache
+----+ -----------------
|LMA | MN:if2 [prefix1] --> MAG2
+----+
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
|
|
if1 if2 |
------[MN]------+
Figure 5: Mobile Node Performs Handover to if2
For the above inter-access technology handover to work, the LMA must
know that this is a handover involving two different interfaces of
the mobile node. The Interface Identifier option if present in the
Proxy Binding Update from MAG2 will have a different identifier from
what is stored in the binding cache entry on the LMA. So this might
appear to the LMA as if the mobile node is attaching via a different
interface. The Proxy Binding Update from MAG2 MUST have the Handoff
Indicator field in the Handoff Indicator option set to "2" or "3" to
indicate that it is a handover. See Section 3.1 for a detailed
description of how MAG2 determines when to indicate in the Proxy
Binding Update that it is a handover.
The mobile node must also be able to move the prefix from if1 to if2
during the handover for the inter-access technology handover to work.
The mobile node should satisfy the requirements listed in Section 4.1
for the handover to work.
4.4. Mobile node with three or more interfaces
This section considers a handover scenario for a mobile node with
three or more interfaces and performing a handover from if1 to if3
while staying connected over if2. It is assumed that the mobile node
is attached to MAG1 using if1, MAG2 using if2 and MAG3 using if3. In
this scenario, even if MAG3 knows that it is a handover, it does not
which two interfaces are involved in the handover. The AAA
infrastructure does not help here since the AAA does not know which
Devarapalli, et al. Expires September 4, 2009 [Page 11]
Internet-Draft PMIPv6 Multiple Interface Support March 2009
interface is being handed off to which one. The only possible
solution here is for the mobile node to tell MAG3 more information
about if1 or the home network prefix assigned to if1 or information
about MAG1. MAG3 may indicate in the Proxy Binding Update
information about if1 or the prefix assigned to if1 in the Proxy
Binding Update sent to the LMA. The LMA uses this information to
assign the prefix that was assigned to if1 to if3 also. In case the
mobile node provides information about MAG1, then MAG3 can contact
MAG1 over a context transfer interface and obtain more information
about if1 or the home network prefix assigned to if1. In all cases,
MAG3 indicates that it is a handover in the Proxy Binding Update.
Yet another handover scenario is where the mobile is attached to MAG1
via if1 and MAG2 via if2, decides to attach to MAG2 via if3 and
perform a handover from the if1 to if3. In this scenario, the mobile
node must indicate to MAG2 that it is performing a handover from if1
by providing information about if1 when attaching to MAG2 using if3.
MAG2 would then treat the attachment over if3 as a handover from if1
and will indicate this in this Proxy Binding Update to the LMA. The
LMA would then assign the same prefix that was previously assigned
for if1. MAG would further treat existing attachment over if2
separately and cause no modifications to the sessions over if2.
5. Security Considerations
This document mainly analyzes some of the scenarios arising out of a
mobile node with multiple interfaces attaching to a Proxy Mobile IPv6
domain. It does not introduce any new security concerns on top of
what is described in the Security Considerations section of [2].
6. IANA Considerations
This document does not request any assignments from IANA.
7. Acknowledgements
Many of the issues related to using Proxy Mobile IPv6 with a mobile
node with multiple interfaces were discussed on the NETLMM mailing
list. This document tries to capture those issues. Therefore the
authors would like to thank all the folks involved in those
discussions.
The authors would also like to think Sri Gundavelli, Kuntal
Chowdhury, Basavaraj Patil, Vidya Narayanan, and George Tsirtsis for
some interesting discussions in this space.
Devarapalli, et al. Expires September 4, 2009 [Page 12]
Internet-Draft PMIPv6 Multiple Interface Support March 2009
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[3] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi,
"Flow Bindings in Mobile IPv6 and Nemo Basic Support",
draft-ietf-mext-flow-binding-00 (work in progress), May 2008.
8.2. Informative References
[4] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
Selection for Mobile IPv6", RFC 5149, February 2008.
[5] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007.
[6] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor
Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[7] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address
Autoconfiguration", RFC 4862, September 2007.
[8] "Linux Port Bonding",
http://linux-ip.net/html/ether-bonding.html .
Authors' Addresses
Vijay Devarapalli
WiChorus
3950 North First Street
San Jose, CA 95134
USA
Email: vijay@wichorus.com
Devarapalli, et al. Expires September 4, 2009 [Page 13]
Internet-Draft PMIPv6 Multiple Interface Support March 2009
Nishi Kant
Stoke
5403 Betsy Ross Drive
Santa Clara, CA 95054
USA
Email: nishi@stoke.com
Heeseon Lim
Stoke
5403 Betsy Ross Drve
Santa Clara, CA 95054
USA
Email: hlim@stoke.com
Christian Vogt
Ericsson Research, NomadicLab
Hirsalantie 11
02420 Jorvas
Finland
Email: christian.vogt@ericsson.com
Devarapalli, et al. Expires September 4, 2009 [Page 14]