One document matched: draft-muhanna-netlmm-multihoming-support-00.txt
NETLMM Working Group A. Muhanna
Internet-Draft M. Khalil
Intended status: Standards Track Nortel Networks
Expires: May 14, 2008 November 11, 2007
Proxy MIPv6 support for Mobile Nodes with Multihoming
draft-muhanna-netlmm-multihoming-support-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 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Proxy Mobile IPv6 is a network-based mobility protocol which provides
IP mobility for a regular IPv6 mobile node without the involvement of
the IPv6 host. Whenever a mobile node is attached to a PMIPv6 domain
via a mobility access gateway, MAG, it appears to the mobile node as
if it is attached to the same home link and thus the mobile node may
think that it is not roaming away from home. An issue has been
raised with respect to the base PMIPv6 protocol support of a mobile
node with multiple physical interfaces. This issue has been
Muhanna & Khalil Expires May 14, 2008 [Page 1]
Internet-Draft PMIPv6 Support for Multihoming November 2007
referenced as PMIPv6 support for multihoming mobile node. This
document describes the multihoming issue as it relates to PMIPv6 and
provides an analysis to all scenarios that have been identified thus
far.
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Multihoming Scenarios . . . . . . . . . . . . . . . . . . . . 4
3.1. Multihoming with a Single Prefix Per Interface . . . . . . 4
3.1.1. Inter-MAG Context Transfer Use . . . . . . . . . . . . 6
3.1.2. Helping AAA Infrastructure Use . . . . . . . . . . . . 6
3.1.3. MN-MAG Interaction via Access Network or L2
Interface . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Multihoming with Single IP Address per Interface . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Muhanna & Khalil Expires May 14, 2008 [Page 2]
Internet-Draft PMIPv6 Support for Multihoming November 2007
1. 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 [1].
All the general mobility terminologies and abbreviations are to be
interpreted as defined in IPv6 Mobility Support specification [RFC-
3775] and Proxy Mobile IPv6 [PMIP6-Base].
2. Introduction
Proxy Mobile IPv6 [PMIP6-Base] is a network-based mobility protocol
which provides IP mobility for a regular IPv6 mobile node without the
involvement of the IPv6 host. When the IPv6 host has a multiple
interfaces which are connected simultaneoulsy, then the base PMIPv6
protocol may not be able to offer mobility to such a mobile node
host. However, in the case that the mobile node has multiple
interfaces where the mobile node does not require simultatneous
binding over these multiple interfaces, then PMIPv6 base protocol
should handle this case in a straight forward fashion. In other
words, in case of inter-technology handoff and when the mobile node
have two different interfaces to access different technologies while
the mobile node have use the simultaneous binding only in the case of
inter-technology handoff, PMIPv6 base protocol may handle this case
quite straight forward without. However, PMIPv6 base protocol does
not specify the mechanism of how the MAG acquire the needed
information for enabling PMIPv6 support for multihoming as per its
general case scenario.
On the other hand, when the IPv6 host use multiple physical
interfaces to simultaneously attach to the same PMIPv6 domain, base
PMIPv6 protocol need further development to address such case and
scenario. These interfaces could be of the same or different types
of accesses. It is also possible that the mobile node may handoff
between different interfaces of the same access type or different
accesses.
In the case when a mobile node is not capable of handling the same
prefix across multiple interfaces, this document provides the
analysis of how PMIPv6 based protocol will enable mobility for such a
case. The following two scenarios have been identified and to some
extent discussed on the netlmm mailing list where the mobile node is
required to use all of its available interfaces simultaneously to
attach to the same PMIPv6 domain.
Muhanna & Khalil Expires May 14, 2008 [Page 3]
Internet-Draft PMIPv6 Support for Multihoming November 2007
o Multihoming with a single prefix per interface.
o Multihoming with single IP address per interface.
3. Multihoming Scenarios
Two multihoming scenarios have been identified as described in the
introduction section. This document provides an analysis of these
scenarios as per the following sections. In all of these scenarios
and in addition to the regular PMIPv6 base protocol required
information, more information specific to the interface ID, access
technology type, and the handoff indication is necessary in order for
PMIPv6 protocol to offer IP mobility support to a mobile node with
multihoming. In PMIPv6 domain, there are several means for the MAG
to acquire these extra information as listed below:
o Availability of Inter-MAG Context Transfer.
o Use of Available AAA Infrastructure.
o Direct MN-MAG Interaction via Access Network or L2 Interface.
Under each of the multihoming scenarios, this analysis will provide
how the MAG may be able to use each of the above resources to enable
PMIPv6 multihoming support as explained and discussed in the sections
below.
3.1. Multihoming with a Single Prefix Per Interface
In this case, every single interface of the IPv6 mobile node is
assigned a specific IPv6 prefix as shown below in Figure 1. In the
case the LMA does not receive any extra information in the P-BU to
inform the LMA with the interface ID, the access type, or the handoff
indicator, the LMA default behavior is to assign a new IPv6 prefix
for each P-BU received for the same MN-ID but from a different MAG.
Muhanna & Khalil Expires May 14, 2008 [Page 4]
Internet-Draft PMIPv6 Support for Multihoming November 2007
LMA Binding Cache
=================
MN1-if1 [prefix1] --> MAG1
MN1-if2 [prefix2] --> MAG2
MN2-if3 [prefix3] --> MAG1
MN2-if4 [prefix4] --> MAG2
if3 +------+
+------------->| | +------+
| if1 | MAG1 |\ +=================+ | |
| +------->| | \ / \ | |
| | +------+ \ / IPv6/IPv4 Transport \ | L |
[MN-2] [MN-1] +--+ ...... +--| M |
| | if2 +------+ / \ IPv6/IPv4 Transport / | A |
| +------->| | / \ / | |
| if4 | MAG2 | / +=================+ | |
+------------->| |/ | |
+------+ +------+
|<---------------- PMIPv6 Domain ---------------->|
Figure 1: PMIPv6 Multihoming Support: A single prefix per interface.
In the case when the Mobile node is able to attach simultaneously to
separate MAGs using different interfaces as per figure 1, LMA will
assign a separate prefix per interface. LMA is able to route each
prefix's traffic after encapsulation to the corresponding MAG which
the MN is attached to using the proper interface. If a mobile node,
e.g. MN2, attaches to adifferent MAG, e.g. MAG2 using interface if4
after it has been attached to MAG1 via if3, LMA will assign prefix4
to MN2 binding and points the binding to MAG2. When MN2 decides to
move and attaches to a different MAG which belongs to the same PMIPv6
domain as per figure 1, e.g. MAG3 using interface if4, MAG3 includes
if4 in the P-BU message. When the LMA receives the P-BU from MAG3,
LMA is able to identify that the MN is handing off over interface if4
to MAG3 and will assign the same prefix4 to maintain session
continuity. In case the interface ID is not available to MAG3, MAG3
Must be able to set the handoff indication field in the Access
Technology Type option to a value which indicates active handoff. If
LMA has only one binding cache entry for the same mobile node ID,
then the LMA would be able to allocate the same prefix and maintain
session continuity.
Muhanna & Khalil Expires May 14, 2008 [Page 5]
Internet-Draft PMIPv6 Support for Multihoming November 2007
3.1.1. Inter-MAG Context Transfer Use
In the case inter-MAG context transfer is available to the target
MAG, the target MAG must receive the interface ID which is the mobile
node is handing over. In this case, both the access technology type
and the handoff indication will be available to the target MAG. If
the above mentioned information is available to the target MAG during
the multihomed mobile node inter-MAG context transfer, the target MAG
will be able to provide the interface ID, the access technology type,
and be able to correctly set the handoff indication in the Access
Technology Type option. When the target MAG sends a P-BU with these
information, LMA will always be able to definitely identify the
mobile node binding cache entry which belongs to the P-BU received
from the target MAG.
3.1.2. Helping AAA Infrastructure Use
The helping AAA infrastructure can be used to enable PMIPv6 support
of multihoming according to the following conditions:
o During Inter MAG handoff, mobile node will perform access
authentication using AAA infrastructure.
o If the MN is performing access authentication during an inter-MAG
handoff, the MN SHOULD provide the AAA infrastructure (AAA server)
with the interface ID that the mobile node is handing off from,
i.e. the previous interface ID.
o If the MN is performing access authentication during an inter-MAG
handoff, the MN SHOULD provide the AAA infrastructure (AAA server)
with the interface ID that the mobile node is handing off from,
i.e. the previous interface ID and in the case that the MN is
handing over to a different interface ID, the mobile node SHOULD
provide the AAA infrastructure with the target interface ID.
o During Access authentication, the target MAG SHOULD be able to
receive the previous and the target interface ID during the mobile
node access authentication or by requesting them directly from the
AAA infrastructure.
o In the case that the target interface ID is different than the
previous interface ID, the target MAG MUST include both the target
and previous interface IDs in the P-BU in order for the LMA to be
able to identify the exact MN binding cache entry.
Muhanna & Khalil Expires May 14, 2008 [Page 6]
Internet-Draft PMIPv6 Support for Multihoming November 2007
3.1.3. MN-MAG Interaction via Access Network or L2 Interface
In the case that neither inter-MAG context transfer is available nor
the help of the AAA infrastructure during access authentication, a
direct communication between the MN and the MAG is required in order
to enable the PMIPv6 multihoming support. In this case the MN MUST
be able to communicate interface and handoff information to access
network during mobile node handoff. The following information need
to be communicated from the MN to the MAG via access network or L2
interface signaling.
o During Inter MAG handoff, the target MAG MUST be able to receive
the mobile node target interface ID from the mobile node, e.g. via
access network.
o In the case that the target interface ID is different from the
previous interface ID during Inter-MAG handoff, the MAG MUST be
able to receive both the target and previous interface IDs.
o The MAG should be able to receive a handoff indication and the
access technology type.
If all the above information are available to the MAG during the MN
inter-MAG handoff, the target MAG MUST include all these information
in the P-BU to aid the LMA in identifying the exact mobile node
binding cache entry. In this case, LMA is able to maintain session
continuity as it is necessary.
3.2. Multihoming with Single IP Address per Interface
This scenario is a special case of the main scenario listed under
section 3.1. In this case the LMA assign a unique IP address for
each interface and maintain separate binding cache entry per
interface. Eventually this scenario causes a multi-link subnet since
the same prefix is advertised over multiple subnets. This scenario
assumes that the mobile node would configure a unique IP address per
interface in the case of static IP address configuration or the MN
will req=uest the IP address via Dynamic Host Control Protocol [RFC-
3315].
Muhanna & Khalil Expires May 14, 2008 [Page 7]
Internet-Draft PMIPv6 Support for Multihoming November 2007
LMA Binding Cache
=================
MN1-if1 [addr1:prefix1] --> MAG1
MN1-if2 [addr2:prefix1] --> MAG2
MN2-if3 [addr3:prefix2] --> MAG1
MN2-if4 [addr4:prefix2] --> MAG2
if3 +------+
+------------->| | +------+
| if1 | MAG1 |\ +=================+ | |
| +------->| | \ / \ | |
| | +------+ \ / IPv6/IPv4 Transport \ | L |
[MN-2] [MN-1] +--+ ...... +--| M |
| | if2 +------+ / \ IPv6/IPv4 Transport / | A |
| +------->| | / \ / | |
| if4 | MAG2 | / +=================+ | |
+------------->| |/ | |
+------+ +------+
|<---------------- PMIPv6 Domain ---------------->|
Figure 2: PMIPv6 Multihoming Support: A single address per interface.
In this scenario it is LMA local policy to assign different prefix
per mobile node or use the same prefix for assigning IP addresses for
multiple mobile nodes. Figure 2 above assumes that the LMA assigns a
single prefix per MN but different IP address for each interface.
4. IANA Considerations
This document does not require any IANA interaction.
5. Security Considerations
This document does not present any new security requirement on the
top of the security requirements listed in [PMIPv6-Base}. It only
present an analysis of PMIPv6 support for multihoming mobile nodes
when connected to the same PMIPv6 domain.
Muhanna & Khalil Expires May 14, 2008 [Page 8]
Internet-Draft PMIPv6 Support for Multihoming November 2007
6. Acknowledgements
The authors would like to thank their colleagues who are willing to
provide comments on the content of this draft.
7. References
7.1. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[PMIP6-Base] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury,
K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-05
(work in progress), September 2007.
[RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
IPv6", RFC 3775, June 2004.
7.2. Informative References
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC-3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R.
Droms,Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. July
2003.
Authors' Addresses
Ahmad Muhanna
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082
USA
Phone: +1 (972) 685-1416
Email: amuhanna@nortel.com
Muhanna & Khalil Expires May 14, 2008 [Page 9]
Internet-Draft PMIPv6 Support for Multihoming November 2007
Mohamed Khalil
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082
USA
Phone: +1 (972) 685-0564
Email: mkhalil@nortel.com
Muhanna & Khalil Expires May 14, 2008 [Page 10]
Internet-Draft PMIPv6 Support for Multihoming November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Muhanna & Khalil Expires May 14, 2008 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 17:00:03 |