Skip to main content

Home Network Prefix Renumbering in PMIPv6
draft-ietf-dmm-hnprenum-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8191.
Authors Zhiwei Yan , Jong-Hyouk Lee , XiaoDong Lee
Last updated 2016-05-20
Replaces draft-yan-dmm-hnprenum
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state In WG Last Call
Other - see Comment Log
Document shepherd (None)
IESG IESG state Became RFC 8191 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-dmm-hnprenum-02
DMM Working Group                                                 Z. Yan
Internet-Draft                                                     CNNIC
Intended status: Standards Track                                  J. Lee
Expires: November 21, 2016                          Sangmyung University
                                                                  X. Lee
                                                                   CNNIC
                                                            May 20, 2016

               Home Network Prefix Renumbering in PMIPv6
                       draft-ietf-dmm-hnprenum-02

Abstract

   In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node
   (MN) is assigned with a 64-bit Home Network Prefix (HNP) during its
   initial attachment for the Home Address (HoA) configuration.  During
   the movement of the MN, this prefix remains unchanged and in this way
   it is unnecessary for the MN to reconfigure its HoA and reconnect the
   ongoing communications.  However, the current PMIPv6 specification
   does not specify related operations to support the MN to timely
   receive and use a new HNP when the allocated HNP changes.  In this
   draft, a solution to support the HNP renumbering is proposed, as an
   update of the PMIPv6 specification.

Requirements Language

   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]

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on November 21, 2016.

Yan, et al.             Expires November 21, 2016               [Page 1]
Internet-Draft           PMIPv6 HNP Renumbering                 May 2016

Copyright Notice

   Copyright (c) 2016 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Usage scenarios . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  PMIPv6 extensions . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Session connectivity  . . . . . . . . . . . . . . . . . . . .   5
   5.  Message format  . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Other issues  . . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security considerations . . . . . . . . . . . . . . . . . . .   6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Network managers currently prefer Provider Independent (PI)
   addressing for IPv6 to attempt to minimize the need for future
   possible renumbering.  However, widespread use of PI addresses may
   cause Border Gateway Protocol (BGP) scaling problems.  It is thus
   desirable to develop tools and practices that may make IPv6
   renumbering a simpler process to reduce demand for IPv6 PI space
   [RFC6879].  In this draft, we aim to solve the HNP renumbering
   problem when the HNP in PMIPv6 [RFC5213] is not the type of PI.

2.  Usage scenarios

   There are a number of reasons why the HNP renumbering support in
   PMIPv6 is useful and a few are identified below:

   o  Scenario 1: the PMIPv6 service provider is assigned with the HNP
      set from the (uplink) Internet Service Provider (ISP), and then

Yan, et al.             Expires November 21, 2016               [Page 2]
Internet-Draft           PMIPv6 HNP Renumbering                 May 2016

      the HNP renumbering may happen if the PMIPv6 service provider
      switches to a different ISP.

   o  Scenario 2: multiple Local Mobility Anchors (LMAs) may be deployed
      by the same PMIPv6 service provider, and then each LMA may serve
      for a specific HNP set.  In this case, the HNP of an MN may change
      if the current serving LMA switches to another LMA but without
      inheriting the assigned HNP set [RFC6463].

   o  Scenario 3: the PMIPv6 HNP renumbering may be caused by the re-
      building of the network architecture as the companies split,
      merge, grow, relocate or reorganize.  For example, the PMIPv6
      service provider may reorganize its network topology.

   In the scenario 1, we assume that only the HNP is renumbered while
   the serving LMA remains unchanged and this is the basic scenario of
   this document.  In the scenario 2 and scenario 3, more complex
   results may be caused, for example, the HNP renumbering may happen
   due to the switchover of serving LMA.

   In the Mobile IPv6 (MIPv6) protocol, when the home network prefix
   changes (may also be caused by the above reasons), the Home Agent
   (HA) will actively notify the new prefix to the MN and then the
   renumbering of the HoA can be well supported [RFC6275].  While in the
   basic PMIPv6, the PMIPv6 binding is triggered by the Mobile Access
   Gateway (MAG), which detected the attachment of the MN.  When the HNP
   renumbering happens, a scheme is also needed for the LMA to
   immediately initiate the PMIPv6 binding state refreshment.  Although
   this issue is also discussed in Section 6.12 of [RFC5213], the
   related solution has not been specified.

3.  PMIPv6 extensions

   When the HNP renumbering happens in PMIPv6, the LMA has to notify the
   new HNP to the MAG and then the MAG has to announce the new HNP to
   the MN accordingly.  Also, the LMA and the MAG must update the
   routing states for the prefixes.  To support this procedure,
   [RFC7077] can be adopted which specifies asynchronously update from
   the LMA to the MAG about the session parameters.  This document
   considers the following two cases:

   (1) HNP is renumbered in the same LMA

   In this case, the LMA remains unchanged as in the scenario 1 and
   scenario 3.  The operation steps are shown in Figure 1.

Yan, et al.             Expires November 21, 2016               [Page 3]
Internet-Draft           PMIPv6 HNP Renumbering                 May 2016

   +-----+                +-----+                +-----+
   | MN  |                | MAG |                | LMA |
   +-----+                +-----+                +-----+
     |                      |                      |
     |                      |           Allocate new HNP
     |                      |                      |
     |                      |<------------- UPN ---|
     |                      |                      |
     |               Update routing state          |
     |                      |                      |
     |<-----RA/DHCP --------|                      |
     |                      |                      |
   HoA Configuration        |                      |
     |                      |                      |
     |                      |--- UNA ------------->|
     |                      |                      |
     |                      |      Update routing state
     |                      |                      |

             Figure 1: Signaling call flow of HNP renumbering

   o  When the PMIPv6 service provider renumbers the HNP set in the same
      LMA, the serving LMA will initiate the HNP renumbering operation.
      The LMA allocates a new HNP for the related MN.

   o  The LMA sends the Update Notification (UPN) message to the MAG to
      update the HNP information.  If the Dynamic Host Configuration
      Protocol (DHCP) is used in PMIPv6 to allocate the HoA, the new HNP
      should be also notified to the DHCP infrastructure.

   o  After the MAG receives this UPN message, it recognizes that the
      related MN has a new HNP.  Then the MAG should notify the MN about
      the new HNP with a Router Advertisement (RA) message or allocate a
      new address within the new HNP with a DHCP message.

   o  When the MN obtains the new HNP information, it deletes the old
      HoA and configures a new HoA with the newly allocated HNP.

   o  The MAG sends back the Update Notification Acknowledgement (UNA)
      to the LMA for the notification of successful update of the HNP,
      related binding state, and routing state.  Then the LMA updates
      the routing information corresponding to the MN to replace the old
      HNP with the new one.

   (2) HNP renumbering caused by LMA switchover

   Because the HNP is assigned by the LMA, the HNP renumbering may be
   caused by the LMA switchover, as in the scenario 2 and scenario 3.

Yan, et al.             Expires November 21, 2016               [Page 4]
Internet-Draft           PMIPv6 HNP Renumbering                 May 2016

   The information of LMA is the basic configuration information of MAG.
   When the LMA changes, the related profile should be updated by the
   service provider.  In this way, the MAG will initiate the re-
   registration to the new LMA as specified in [RFC5213].  When the HNP
   renumbering is caused in this case, the new HNP information will be
   sent by the LMA during the new binding procedure.  Accordingly, the
   MAG will withdraw the old HNP information of the MN and advise the
   new HNP to the MN as the 3rd Step in Section 3(1).

4.  Session connectivity

   HNP renumbering may cause the disconnection of the ongoing
   communications of the MN.  Basically, there are two modes to manage
   the session connectivity during the HNP renumbering.

   (1) Soft-mode

   The LMA will temporarily maintain the state of the old HNP during the
   HNP renumbering (after the UNA reception) in order to redirect the
   packets to the MN before the MN reconnects the ongoing session and
   notifies its new HoA to the Correspondent Node (CN).  This mode is
   aiming to reduce the packet loss during the HNP renumbering but the
   binding state and routing entry corresponding to the old HNP should
   be marked for example as transient binding [RFC6058].  This temporary
   binding should only be used for the downwards packet transmission and
   the LMA should not broadcast the routing information about the old
   HNP if it is no longer anchored at this LMA.

   (2) Hard-mode

   If the HNP renumbering happens with the switchover of the LMA, the
   hard-mode is recommended to keep the protocol simple and efficient.In
   this mode, the LMA will delete the state of the old HNP after it
   receives the UNA message from MAG and the LMA will silently discard
   the packets destined to the old HNP.

5.  Message format

   (1) UPN message

   In the UPN message sent from the LMA to the MAG, the notification
   reason is set to 2 (UPDATE-SESSION-PARAMETERS).  Besides, the HNP
   option containing the new HNP and the Mobile Node Identifier option
   carrying Identifier of MN are contained as Mobility Options of UPN.

   (2) RA Message

Yan, et al.             Expires November 21, 2016               [Page 5]
Internet-Draft           PMIPv6 HNP Renumbering                 May 2016

   When the RA message is used by the MAG to advise the new HNP, two
   Prefix Information options are contained in the RA message [RFC4861].
   In the first Prefix Information option, the old HNP is carried but
   both the related Valid Lifetime and Preferred Lifetime are set to 0.
   In the second Prefix Information option, the new HNP is carried with
   the Valid Lifetime and Preferred Lifetime set to larger than 0.

   (3) DHCP Message

   When the DHCP is used in PMIPv6 to configure the HoA for the MN, a
   new IPv6 HoA is generated based on the new HNP.  Trigged by the UPN
   message, the MAG will request the new HoA from the DHCP server first
   and then the MAG updates the allocated HoA to the MN through the DHCP
   server-initiated configuration exchange [RFC3315].

6.  Other issues

   In order to maintain the reachability of the MN, the Domain Name
   System (DNS) resource record corresponding to this MN may need to be
   updated when the HNP of MN changes [RFC3007].  However, this is out
   the scope of this draft.

7.  Security considerations

   This extension causes no further security problem.  The security
   considerations in [RFC5213] and [RFC7077] are enough for the basic
   operation of this draft.

8.  IANA Considerations

   This document presents no IANA considerations.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
              <http://www.rfc-editor.org/info/rfc3007>.

Yan, et al.             Expires November 21, 2016               [Page 6]
Internet-Draft           PMIPv6 HNP Renumbering                 May 2016

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <http://www.rfc-editor.org/info/rfc3315>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <http://www.rfc-editor.org/info/rfc4861>.

   [RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
              Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
              RFC 5213, DOI 10.17487/RFC5213, August 2008,
              <http://www.rfc-editor.org/info/rfc5213>.

   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
              2011, <http://www.rfc-editor.org/info/rfc6275>.

   [RFC6463]  Korhonen, J., Ed., Gundavelli, S., Yokota, H., and X. Cui,
              "Runtime Local Mobility Anchor (LMA) Assignment Support
              for Proxy Mobile IPv6", RFC 6463, DOI 10.17487/RFC6463,
              February 2012, <http://www.rfc-editor.org/info/rfc6463>.

   [RFC7077]  Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and
              J. Korhonen, "Update Notifications for Proxy Mobile IPv6",
              RFC 7077, DOI 10.17487/RFC7077, November 2013,
              <http://www.rfc-editor.org/info/rfc7077>.

9.2.  Informative References

   [RFC6058]  Liebsch, M., Ed., Muhanna, A., and O. Blume, "Transient
              Binding for Proxy Mobile IPv6", RFC 6058,
              DOI 10.17487/RFC6058, March 2011,
              <http://www.rfc-editor.org/info/rfc6058>.

   [RFC6879]  Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
              Network Renumbering Scenarios, Considerations, and
              Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013,
              <http://www.rfc-editor.org/info/rfc6879>.

Authors' Addresses

Yan, et al.             Expires November 21, 2016               [Page 7]
Internet-Draft           PMIPv6 HNP Renumbering                 May 2016

   Zhiwei Yan
   CNNIC
   No.4 South 4th Street, Zhongguancun
   Beijing  100190
   China

   EMail: yan@cnnic.cn

   Jong-Hyouk Lee
   Sangmyung University
   31, Sangmyeongdae-gil, Dongnam-gu
   Cheonan
   Republic of Korea

   EMail: jonghyouk@smu.ac.kr

   Xiaodong Lee
   CNNIC
   No.4 South 4th Street, Zhongguancun
   Beijing  100190
   China

   EMail: xl@cnnic.cn

Yan, et al.             Expires November 21, 2016               [Page 8]