summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8191.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8191.txt')
-rw-r--r--doc/rfc/rfc8191.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc8191.txt b/doc/rfc/rfc8191.txt
new file mode 100644
index 0000000..43e6e9e
--- /dev/null
+++ b/doc/rfc/rfc8191.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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]
+