From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8191.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc8191.txt (limited to 'doc/rfc/rfc8191.txt') 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, + . + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, + . + + [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, . + + [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, + . + + [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, + . + + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", RFC 4862, + DOI 10.17487/RFC4862, September 2007, + . + + [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., + Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", + RFC 5213, DOI 10.17487/RFC5213, August 2008, + . + + [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility + Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July + 2011, . + + [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, . + + + + + +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, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + +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, + . + + [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise + Network Renumbering Scenarios, Considerations, and + Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013, + . + + [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, + . + + + + + + + + + + + + + + + + + + + + + + + + + + +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] + -- cgit v1.2.3