Netlmm Working Group D. Oulai
Internet-Draft S. Krishnan
Intended status: Standards Track Ericsson
Expires: January 8, 2009 July 7, 2008
IPv4 support in PMIP-MIP interaction
draft-oulai-netlmm-mip-interaction-v4support-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 January 8, 2009.
Oulai & Krishnan Expires January 8, 2009 [Page 1]
Internet-Draft IPv4 support in PMIP-MIP interaction July 2008
Abstract
PMIPv6 and MIPv6 are respectively the leading protocols for network
based and client based mobility. As backward compatibility is an
important feature, IPv4 support for PMIPv6 and MIPv6 becomes
mandatory. This document highlights some scenarios for PMIPv6-MIPv6
interaction with IPv4 support as well as some proposed solutions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Scenario Analysis . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Scenario C . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Oulai & Krishnan Expires January 8, 2009 [Page 2]
Internet-Draft IPv4 support in PMIP-MIP interaction July 2008
1. Introduction
MIPv6 is the IETF standard for client-based mobility [RFC3775] and
PMIPv6 is an extension of MIPv6 developped to offer network-based
mobility [I-D.ietf-netlmm-proxymip6]. For those two protocols,
backward compatibility is important and that is why IPv4 support
becomes mandatory. The IPv4 support for MIPv6 is provided by DSMIP
[I-D.ietf-mext-nemo-v4traversal] and PMIPv6-v4 handles the v4 support
for PMIPv6 [I-D.ietf-netlmm-pmip6-ipv4-support].
Due to different reasons and network operator preferences, MIPv6 and
PMIPv6 will have to interact. A work is ongoing on PMIPv6-MIPv6
interaction [I-D.giaretta-netlmm-mip-interactions]. Three scenarios
have been presented.
* Scenario A: Two distincts PMIPv6 domains inside a single MIPv6
domain.
* Scenario B: A single domain where PMIPv6 and MIPv6 are offered.
* Scenario C: A colocated LMA/HA serving distincts PMIPv6 and MIPv6
domain.
In this document, we tackle the v4 support of this PMIPv6/MIPv6
interaction (PMIPv6-v4/DSMIP). First, note that we will not address
scenario B mentioned in [I-D.giaretta-netlmm-mip-interactions] as it
will not involve any handover. Direct applications of
[I-D.ietf-netlmm-pmip6-ipv4-support] and
[I-D.ietf-mext-nemo-v4traversal] can offer v4 support in scenario B.
For each remaining scenarios, we have to consider the case where both
source and target networks have v4 support and the case where target
network do not offer v4 support. Moreover, for scenario A, it is
possible that the global MIPv6 used for macro-mobility does not
support IPv4.
Oulai & Krishnan Expires January 8, 2009 [Page 3]
Internet-Draft IPv4 support in PMIP-MIP interaction July 2008
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Oulai & Krishnan Expires January 8, 2009 [Page 4]
Internet-Draft IPv4 support in PMIP-MIP interaction July 2008
3. Scenario Analysis
In this section, we analyze and provide solutions for scenarios A and
C depicted in [I-D.giaretta-netlmm-mip-interactions]
3.1. Scenario A
In this scenario, we have two distincts PMIPv6 domains P1 and P2
inside a single global MIPv6 domain G. In case where both P1 and P2
do not support v4, the MN will use DSMIP with the HA to support v4
applications and mobility. For the remaining part of this section,
we assume that the MN is in the domain P1 that offers v4 support as
depicted in [I-D.ietf-netlmm-pmip6-ipv4-support]. Using PMIPv6-v4,
the MN acquires an IPv6 and an IPv4 HoA. Several situations could
occur.
* G domain supports v4
Beforehand, MN has to run the DSMIP bootstrapping mechanism while
residing in P1 to obtain DSMIP v6 and v4 HoA anchored at the HA.
Then, MN registers its PMIPv6 v6 or v4 HoA as CoA with HA while still
in P1. Preference is given to the v6 address in this case as there
can only be one CoA. All the v6 and v4 traffic flowing through HA
will be tunneled to MN using the CoA. The MN SHOULD use the v4 HoA
anchored at the HA at the transport level as the v4 CoA may change
after handover. However, the MN could use the v4 CoA for short-term
connections
v4 support in domain P2 : When moving to a P2 domain that offers v4
support, the MN acquires new v6 and v4 address. It registers its new
PMIPv6 v6 HoA as CoA with HA. All the v4 traffic from HA will be
encapsulated towards this CoA and the MN will encapsulate the v4
traffic with the HA address. The MN SHOULD use the v4 HoA anchored
at the HA at the transport level as the CoA may change after
handover.
No v4 support in domain P2 : In this case, the same process described
above is applyed except that the MN will not get a new PMIPv6 v4 HoA.
v4 support is handled by MN and HA running DSMIP.
* G domain does not supports v4
In this case, the v4 traffic is handled by the LMA1, the LMA in the
domain P1 using PMIPv6-v4 [I-D.ietf-netlmm-pmip6-ipv4-support]. We
recommand that LMA1 includes some DSMIP functionnalities. We will
have a colocated LMA1/HA1, similar to the one depicted in scenario C
of [I-D.giaretta-netlmm-mip-interactions] . The MN SHOULD be aware
that there is no v4 support at HA in domain G.
Oulai & Krishnan Expires January 8, 2009 [Page 5]
Internet-Draft IPv4 support in PMIP-MIP interaction July 2008
We also recommand to keep the v4 anchor identity in a policy profile.
If domain G supports v4, HA is the v4 anchor and if not, LMA1 is the
v4 anchor. After the handover in P2 and the PMIPv6 bootstrapping,
the MN interacts with the policy profile to get the v4 anchor (LMA1)
address and start a DSMIP bootstrapping process with LMA1. The MN
SHOULD include its previous v4 HoA in the IKEv2 exchange so this
address will be used as DSMIP v4 HoA at the LMA1. Therefore, the MN
will be able to continue using this address for v4 traffic.
For v6 trafic, implementation has two choices. First one is to keep
the tunneling between HA and LMA1 then tunnels the packet to the new
address in domain P2. The second option is to update the BCE at the
HA in the global domain to receive directly the v6 packets from the
HA. This is possible as v6 and v4 bindings are independent.
However, we recommend the first choice for simplicity.
3.2. Scenario C
We assume that the MN starts in a domain that offers v4 support. The
MN configures v6 and v4 HoA.
* Handover PMIPv6-MIPv6
MIPv6 domain supports v4 : In the DSMIP bootstrapping mechanism, the
addresses acquired in the PMIP domain are considered as v6 and v4 HoA
by the HA. For this purpose, a hint must be included in the IKEv2
exchange as mentioned in [I-D.giaretta-netlmm-mip-interactions]. MN
acquires new v4 and v6 addresses and registers the v6 address as CoA
with HA. Depending on the transport network in the MIPv6 domain, v4
or v6 encapsulation may be used. The principles of DSMIP will rule
the signaling and data transport. Also, the Binding Cache lookup
considerations as presented in [I-D.giaretta-netlmm-mip-interactions]
will also be applied.
MIPv6 domain does not support v4 : In this case, as the LMA and the
HA are colocated, the BCE at the HA will be modified to consider the
v4 HoA and the principles of DSMIP could be applied.
* Handover MIPv6-PMIPv6
PMIPv6 domain supports v4 : The addresses acquired in the MIPv6
domain are considered as v6 and v4 HoA by the LMA. The LMA will
propose the same Home Network Prefixes (HNP) as in the MIPv6 domain.
For this purpose, the HNP MUST be reserved as mentioned in
[I-D.ietf-netlmm-pmip6-ipv4-support]. PMIPv6-v4 will rule the
signaling and data transport. The Binding Cache lookup
considerations will be applied as presented in
[I-D.giaretta-netlmm-mip-interactions] .
Oulai & Krishnan Expires January 8, 2009 [Page 6]
Internet-Draft IPv4 support in PMIP-MIP interaction July 2008
PMIPv6 domain does not support v4 : In this case, the MN will used
the v6 HoA in the PMIP domain. The MN will send a binding update to
the HA. A modification is required to DSMIP allowing to have only a
v4 HoA. The BU message will tell the HA to keep only the v4 HoA in
the BCE and remove the v6 HoA. The MN will have two BCE. Therefore,
packets coming with the v6 HoA will be handled by the LMA and
forwarded to the MAG and packets coming with v4 address will be
handled by the HA, encapsulated and forwarded to the v6 HoA which is
the PMIPv6 v6 HoA. Another choice could be to configure a new v6
address in the PMIP domain and register it as CoA with the HA as in
scenario A.
Oulai & Krishnan Expires January 8, 2009 [Page 7]
Internet-Draft IPv4 support in PMIP-MIP interaction July 2008
4. Security Considerations
This document do not bring any new security issues compared to
[I-D.giaretta-netlmm-mip-interactions] . The BCE handling in
scenario C is the major task.
Oulai & Krishnan Expires January 8, 2009 [Page 8]
Internet-Draft IPv4 support in PMIP-MIP interaction July 2008
5. IANA Considerations
TBD
Oulai & Krishnan Expires January 8, 2009 [Page 9]
Internet-Draft IPv4 support in PMIP-MIP interaction July 2008
6. Normative References
[I-D.giaretta-netlmm-mip-interactions]
Giaretta, G., "Interactions between PMIPv6 and MIPv6:
scenarios and related issues",
draft-giaretta-netlmm-mip-interactions-02 (work in
progress), November 2007.
[I-D.ietf-mext-nemo-v4traversal]
Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", draft-ietf-mext-nemo-v4traversal-04 (work in
progress), June 2008.
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-03
(work in progress), May 2008.
[I-D.ietf-netlmm-proxymip6]
Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-18 (work in progress),
May 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Oulai & Krishnan Expires January 8, 2009 [Page 10]
Internet-Draft IPv4 support in PMIP-MIP interaction July 2008
Authors' Addresses
Desire Oulai
Ericsson
8400 Blvd Decarie
Town of Mount Royal, Quebec
Canada
Email: desire.oulai@ericsson.com
Suresh Krishnan
Ericsson
8400 Blvd Decarie
Town of Mount Royal, Quebec
Canada
Email: Suresh.Krishnan@ericsson.com
Oulai & Krishnan Expires January 8, 2009 [Page 11]
Internet-Draft IPv4 support in PMIP-MIP interaction July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Oulai & Krishnan Expires January 8, 2009 [Page 12]