[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/