    Internet Engineering Task Force (IETF)                            Z. Yan
    Request for Comments: 8191                                         CNNIC
    Category: Standards Track                                         J. Lee
    ISSN: 2070-1721                                     Sangmyung University
                                                                      X. Lee
                                                                       CNNIC
                                                                 August 2017

         Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6)

    Abstract

       In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node
       (MN) is assigned with a Home Network Prefix (HNP) during its initial
       attachment, and the MN configures its Home Address (HoA) with the
       HNP.  During the movement of the MN, the HNP remains unchanged to
       keep ongoing communications associated with the HoA.  However, the
       current PMIPv6 specification does not specify related operations when
       HNP renumbering has occurred (e.g., due to change of service provider
       or site topology, etc.).  In this document, a solution to support HNP
       renumbering is proposed, as an optional extension of the PMIPv6
       specification.

    Status of This Memo

       This is an Internet Standards Track document.

       This document is a product of the Internet Engineering Task Force
       (IETF).  It represents the consensus of the IETF community.  It has
       received public review and has been approved for publication by the
       Internet Engineering Steering Group (IESG).  Further information on
       Internet Standards is available in Section 2 of RFC 7841.

       Information about the current status of this document, any errata,
       and how to provide feedback on it may be obtained at
       http://www.rfc-editor.org/info/rfc8191.

    Yan, et al.                  Standards Track                    [Page 1]

    RFC 8191                 PMIPv6 HNP Renumbering              August 2017

    Copyright Notice

       Copyright (c) 2017 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
         1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
       2.  Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . .   3
       3.  HNP Renumbering Procedure . . . . . . . . . . . . . . . . . .   4
       4.  Session Connectivity  . . . . . . . . . . . . . . . . . . . .   6
       5.  Message Format  . . . . . . . . . . . . . . . . . . . . . . .   6
       6.  Other Issues  . . . . . . . . . . . . . . . . . . . . . . . .   7
       7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
       8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
       9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
         9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
         9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
       Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
       Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

    Yan, et al.                  Standards Track                    [Page 2]

    RFC 8191                 PMIPv6 HNP Renumbering              August 2017

    1.  Introduction

       At the time of writing, network managers prefer Provider-Independent
       (PI) addressing for IPv6 to attempt to minimize the need for future
       possible renumbering.  However, a widespread use of PI addresses will
       cause Border Gateway Protocol (BGP) scaling problems [RFC7010].  It
       is thus desirable to develop tools and practices that make IPv6
       renumbering a simpler process to reduce demand for IPv6 PI space
       [RFC6879].  In this document, we aim to support HNP renumbering when
       the HNP in PMIPv6 [RFC5213] is not a PI prefix.

    1.1.  Requirements Language

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
       "OPTIONAL" in this document are to be interpreted as described in BCP
       14 [RFC2119] [RFC8174] when, and only when, they appear in all
       capitals, as shown here.

    2.  Usage Scenarios

       There are a number of reasons why HNP renumbering support in PMIPv6
       is useful, and some scenarios are identified below:

       Scenario 1:  the HNP set used by a PMIPv6 service provider is
                    assigned by a different Internet Service Provider (ISP),
                    and then HNP renumbering MAY occur if the PMIPv6 service
                    provider switches to a different ISP.

       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 serving LMA is changed to
                    another LMA that does not inherit the assigned HNP set
                    [RFC6463].

       Scenario 3:  PMIPv6 HNP renumbering MAY be caused by the rebuilding
                    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 Scenario 1, we assume that only the HNP is renumbered, while the
       serving LMA remains unchanged; this is the basic scenario considered
       in this document.  In Scenarios 2 and 3, more complex situations MAY
       result; for example, HNP renumbering MAY occur due to the switchover
       of a serving LMA.

    Yan, et al.                  Standards Track                    [Page 3]

    RFC 8191                 PMIPv6 HNP Renumbering              August 2017

       In the Mobile IPv6 (MIPv6) protocol, when an HNP changes, the Home
       Agent (HA) will actively notify its MN about the new prefix, and then
       the renumbering of the Home Network Address (HoA) can be well
       supported [RFC6275].  In basic PMIPv6, the PMIPv6 binding is
       triggered by a Mobile Access Gateway (MAG), which detects the
       attachment of the MN.  A scheme is also needed for the LMA to
       immediately initiate the PMIPv6 binding state refreshment during the
       HNP renumbering process.  Although this issue is also mentioned in
       Section 6.12 of [RFC5213], the related solution has not been
       specified.

    3.  HNP Renumbering Procedure

       When HNP renumbering happens in PMIPv6, the LMA MUST notify the MAG
       about the new HNP, and then the MAG MUST announce the new HNP to the
       attached MN accordingly.  Also, the LMA and the MAG MUST update the
       routing states for the HNP and the related addresses.  To support
       this procedure, [RFC7077] can be adopted; it specifies an
       asynchronous update from the LMA to the MAG about specific session
       parameters.  This document considers the following two cases:

       (1) HNP is renumbered under the same LMA

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

           +-----+                +-----+                +-----+
           | MN  |                | MAG |                | LMA |
           +-----+                +-----+                +-----+
             |                      |                      |
             |                      |           Allocate new HNP
             |                      |                      |
             |                      |<------------- UPN ---|
             |                      |                      |
             |                      |                      |
             |                      |                      |
             |<-----RA/DHCP --------|                      |
             |                      |                      |
           Address configuration    |                      |
             |                      |                      |
             |            Update binding & routing states  |
             |                      |                      |
             |                      |--- UPA ------------->|
             |                      |                      |
             |                      |     Update binding & routing states
             |                      |                      |

                 Figure 1: Signaling Call Flow for HNP Renumbering

    Yan, et al.                  Standards Track                    [Page 4]

    RFC 8191                 PMIPv6 HNP Renumbering              August 2017

           o  When a PMIPv6 service provider renumbers the HNP set under the
              same LMA, the serving LMA SHOULD 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 to allocate the address,
              the DHCP infrastructure MUST also be notified about the new
              HNP.

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

           o  After the MN obtains the HNP information through the RA
              message, it deletes the old HoA and configures a new HoA with
              the newly allocated HNP.

           o  When the new HNP is announced or the new address is configured
              to the MN successfully, the MAG MUST update the related
              binding and routing states.  Then, the MAG sends back the
              Update Notification Acknowledgement (UPA) message to the LMA
              for the notification of successful update of the HNP, related
              binding state, and routing state.  Then, the LMA updates the
              routing and binding information corresponding to the MN in
              order to replace the old HNP with the new one.

       (2) HNP renumbering is caused by the LMA switchover

           Since the HNP is assigned by the LMA, HNP renumbering MAY be
           caused by the LMA switchover, as in Scenarios 2 and 3.

           The LMA information is the basic configuration information of the
           MAG.  When the LMA changes, the related profile SHOULD be updated
           by the service provider.  In this way, the MAG initiates the
           binding registration to the MN's new LMA as specified in
           [RFC5213].  When HNP renumbering is caused in this case, the new
           HNP information is sent by the LMA during the new binding
           procedure.  Accordingly, the MAG withdraws the old HNP of the MN
           and announces the new HNP to the MN, similar to the case when the
           HNP is renumbered under the same LMA.

    Yan, et al.                  Standards Track                    [Page 5]

    RFC 8191                 PMIPv6 HNP Renumbering              August 2017

    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 HNP renumbering.

       (1)  Soft mode

            The LMA will temporarily maintain the state of the old HNP
            during the HNP renumbering (after the UPA reception) in order to
            redirect the packets to the MN before the MN reconnects the
            ongoing session and notifies the Correspondent Node (CN) about
            its new HoA.  This mode is aiming to reduce packet loss during
            HNP renumbering, but the binding state corresponding to the old
            HNP SHOULD be marked, for example, as transient binding
            [RFC6058].  Also, the LMA MUST stop broadcasting the routing
            information about the old HNP if the old HNP is no longer
            anchored at this LMA.

       (2)  Hard mode

            If HNP renumbering happens with the switchover of the LMA, hard
            mode is RECOMMENDED to keep the protocol simple.  In this mode,
            the LMA deletes the binding state of the old HNP after it
            receives the UPA message from the MAG, and the LMA silently
            discards 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 [RFC5213] containing the new HNP and the
            Mobile Node Identifier Option [RFC4283] (which identifies the
            MN) are contained as Mobility Options of UPN.  The order of the
            HNP Option and Mobile Node Identifier Option in the UPN message
            is not mandated here.

       (2)  UPA message

            The MAG sends this message in order to acknowledge that it has
            received an UPN message with the (A) flag set and to indicate
            the status after processing the message.  If the MAG did not
            successfully renumber the HNP, which is required in the UPN
            message, the UPA message has the Status Code set to 128 (FAILED-
            TO-UPDATE-SESSION-PARAMETERS), and the subsequent operation of
            the LMA is PMIPv6 service provider specific.

    Yan, et al.                  Standards Track                    [Page 6]

    RFC 8191                 PMIPv6 HNP Renumbering              August 2017

       (3)  RA message

            When the RA message is used by the MAG to advise the new HNP, it
            contains two Prefix Information Options [RFC4861] [RFC4862].  In
            the first Prefix Information Option, the old HNP is carried, and
            the related Preferred Lifetime is 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.

       (4)  DHCP message

            When the DHCP is used in PMIPv6 to configure the addresses for
            the MN, new IPv6 address or addresses (e.g., the HoA) will be
            generated based on the new HNP, and the related DHCP procedure
            is also triggered by the reception of the UPN message [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 the MN changes [RFC3007].  However, this is
       beyond the scope of this document.

    7.  Security Considerations

       The UPN and UPA messages in this document MUST be protected using
       end-to-end security association(s) offering integrity and data origin
       authentication as specified in [RFC5213] and [RFC7077].

       When HNP renumbering is triggered, a new HNP SHOULD be allocated to
       the MN.  The LMA MUST follow the procedure of PMIPv6 to make sure
       that only an authorized HNP can be assigned for the MN.  In this way,
       the LMA is ready to be the topological anchor point of the new HNP,
       which is for that MN's exclusive use.

       Per [RFC4862], if the Valid Lifetime in a Prefix Information Option
       is set to less than 2 hours in an unauthenticated RA, it is ignored.
       Thus, when the old HNP that is being deprecated is included in an RA
       from the MAG, the Valid Lifetime SHOULD be set to 2 hours (and the
       Preferred Lifetime set to 0) for an unauthenticated RA.  However, if
       the legality of the signaling messages exchanged between MAG and MN
       can be guaranteed, it MAY be acceptable to also set the Valid
       Lifetime to 0 for an unauthenticated RA.

    8.  IANA Considerations

       This document does not require any IANA actions.

    Yan, et al.                  Standards Track                    [Page 7]

    RFC 8191                 PMIPv6 HNP Renumbering              August 2017

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

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

       [RFC4283]  Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
                  Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
                  (MIPv6)", RFC 4283, DOI 10.17487/RFC4283, November 2005,
                  <http://www.rfc-editor.org/info/rfc4283>.

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

       [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
                  Address Autoconfiguration", RFC 4862,
                  DOI 10.17487/RFC4862, September 2007,
                  <http://www.rfc-editor.org/info/rfc4862>.

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

    Yan, et al.                  Standards Track                    [Page 8]

    RFC 8191                 PMIPv6 HNP Renumbering              August 2017

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

       [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                  2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                  May 2017, <http://www.rfc-editor.org/info/rfc8174>.

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

       [RFC7010]  Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W.
                  George, "IPv6 Site Renumbering Gap Analysis", RFC 7010,
                  DOI 10.17487/RFC7010, September 2013,
                  <http://www.rfc-editor.org/info/rfc7010>.

    Yan, et al.                  Standards Track                    [Page 9]

    RFC 8191                 PMIPv6 HNP Renumbering              August 2017

    Acknowledgements

       The work of Jong-Hyouk Lee was supported by 'The Cross-Ministry Giga
       KOREA Project' grant from the Ministry of Science, ICT and Future
       Planning, Korea.

    Authors' Addresses

       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  31066
       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.                  Standards Track                   [Page 10]