PMIPv6 HNP Renumbering: Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6)
How a Proxy Mobile IPv6 network tells a device its home prefix has changed, without the device doing anything special.
Yan, Z., Lee, J., and X. Lee, "Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6)", RFC 8191, DOI 10.17487/RFC8191, August 2017, <https://www.rfc-editor.org/info/rfc8191>.
@misc{rfc8191,
series = {Request for Comments},
number = 8191,
howpublished = {RFC 8191},
publisher = {RFC Editor},
doi = {10.17487/RFC8191},
url = {https://www.rfc-editor.org/info/rfc8191},
author = {Z. Yan and J. Lee and X. Lee},
title = {{Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6)}},
pagetotal = 10,
year = 2017,
month = aug,
} RFC text
Contents
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.
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
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.
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
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.
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.
(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.
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>.
[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>.
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
AI ELI5
On this page
§1Why Prefixes Need to Change
In Proxy Mobile IPv6 (PMIPv6, RFC 5213) a Mobile Node (MN) gets a Home Network Prefix (HNP) when it first attaches, and builds its Home Address (HoA) from it. The HNP stays the same while the node moves, so ongoing communication tied to the HoA keeps working.
The base specification does not say what happens when the HNP itself must change. This document adds an optional extension for that case. It aims at HNPs that are not Provider-Independent (PI) prefixes, because the text notes that widespread use of PI addresses causes BGP scaling problems (RFC 7010) and that tools which make IPv6 renumbering simpler reduce demand for PI space (RFC 6879).
Your street name can change. The base rules for travelling devices never said how to tell a traveller about that, so this document adds the missing steps.
§2Usage Scenarios
The RFC lists three situations where renumbering may happen:
- Scenario 1: the HNP set comes from a different ISP, and the PMIPv6 provider switches to another ISP.
- Scenario 2: a provider runs several Local Mobility Anchors (LMAs), each serving its own HNP set, and the node moves to an LMA that does not inherit its assigned HNP set (RFC 6463).
- Scenario 3: the provider rebuilds its network because companies split, merge, grow, relocate or reorganize.
Scenario 1 is the basic case: only the HNP changes and the serving LMA stays the same. In Scenarios 2 and 3 the situation can be more complex, for example when the serving LMA is switched.
In plain Mobile IPv6 the Home Agent actively tells the node about a new prefix (RFC 6275). In PMIPv6 the binding is normally triggered by the Mobile Access Gateway (MAG), so the LMA needs a way to start the update itself. RFC 5213 mentions this in its Section 6.12, but gives no solution.
Sometimes the whole neighbourhood is renamed, sometimes you move to a different post office. In both cases someone has to tell you the new address.
§3The Renumbering Procedure
When renumbering happens, the LMA MUST notify the MAG about the new HNP. The MAG MUST then announce it to the attached node, and both sides MUST update their routing state. The RFC reuses the asynchronous update mechanism of RFC 7077.
Same LMA. The serving LMA SHOULD start the operation and allocates a new HNP. It sends an Update Notification (UPN) to the MAG; if DHCP is used, the DHCP infrastructure MUST also learn the new HNP. The MAG MUST tell the node, either by a Router Advertisement (RA) or by allocating a new address inside the new HNP through DHCP. The node deletes the old HoA and configures a new one. Once that works, the MAG MUST update its binding and routing state and returns an Update Notification Acknowledgement (UPA), after which the LMA replaces the old HNP with the new one.
LMA switchover. The provider SHOULD update the LMA information in the MAG's profile. The MAG then registers with the new LMA as in RFC 5213, the new HNP arrives during that binding, and the MAG withdraws the old HNP and announces the new one, much as in the same-LMA case.
The post office (LMA) tells the hotel front desk (MAG) the new address. The front desk tells you, you swap the address on your luggage, and the front desk confirms back to the post office.
- UPNAfter the LMA allocates a new HNP, it notifies the MAG.
- RA / DHCPThe MN is told the new HNP and configures a new address.
- UPABinding and routing states updated; the LMA then updates its own.
§4Session Connectivity: Soft and Hard Mode
Renumbering MAY break ongoing communication, so the RFC describes two ways to manage sessions.
In soft mode the LMA temporarily keeps the state of the old HNP after receiving the UPA. This lets it redirect packets to the node until the node reconnects its session and tells the Correspondent Node (CN) about its new HoA. The aim is less packet loss. The old binding SHOULD be marked, for example as a transient binding (RFC 6058), and the LMA MUST stop advertising routing information for the old HNP if that HNP is no longer anchored at this LMA.
In hard mode the LMA deletes the old HNP binding state once it receives the UPA and silently discards packets destined to the old HNP. Hard mode is RECOMMENDED when renumbering comes with an LMA switchover, because it keeps the protocol simple.
Soft mode is like keeping mail forwarding on for a while after you move. Hard mode is like cutting off the old address right away, which is simpler but some mail gets lost.
§5Message Contents
The RFC does not define new message types. It says how existing ones are filled in:
- UPN: sent from LMA to MAG with the notification reason set to
2(UPDATE-SESSION-PARAMETERS). It carries the HNP Option with the new HNP and the Mobile Node Identifier Option (RFC 4283), in either order. - UPA: acknowledges a UPN that had the (A) flag set. If the MAG could not renumber, the Status Code is
128(FAILED-TO-UPDATE-SESSION-PARAMETERS), and what the LMA does next is specific to the provider. - RA: carries two Prefix Information Options (RFC 4861, RFC 4862). The first holds the old HNP with Preferred Lifetime set to 0. The second holds the new HNP with Valid and Preferred Lifetimes larger than 0.
- DHCP: new addresses, such as the HoA, are generated from the new HNP, and the procedure is triggered by receiving the UPN (RFC 3315).
No new kinds of letters are invented. The same old forms are reused, with the boxes filled in so they say: stop using this address, start using that one.
§6Security and Other Issues
The UPN and UPA messages MUST be protected with security associations that give integrity and data origin authentication, as in RFC 5213 and RFC 7077. The LMA MUST follow the normal PMIPv6 procedure so that only an authorized HNP is assigned to the node, and the new HNP is for that node's exclusive use.
There is also a subtle RA detail. Per RFC 4862, an unauthenticated RA whose Prefix Information Option has a Valid Lifetime under 2 hours is ignored. So when the MAG deprecates the old HNP in an unauthenticated RA, the Valid Lifetime SHOULD be 2 hours with Preferred Lifetime 0. If the signalling between MAG and node is known to be legitimate, setting the Valid Lifetime to 0 MAY be acceptable.
Updating the node's DNS record may be needed to keep it reachable (RFC 3007), but that is out of scope. The document needs no IANA actions.
Only trusted people may change the address book, and the old address is kept on the list for a short while so nobody can trick the hotel into throwing it away instantly.