DMM Working Group Z. Yan
Internet-Draft CNNIC
Intended status: Standards Track J. Lee
Expires: October 14, 2015 Sangmyung University
X. Lee
CNNIC
April 12, 2015
Home Network Prefix Renumbering in PMIPv6
draft-yan-dmm-hnprenum-01.txt
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 protocol (RFC5213)
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 possible solution to support the HNP renumbering is
proposed, as an update of RFC5213.
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 RFC 2119.
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 October 14, 2015.
Yan, et al. Expires October 14, 2015 [Page 1]
Internet-Draft PMIPv6 HNP Renumbering April 2015
Copyright Notice
Copyright (c) 2015 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. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Message format . . . . . . . . . . . . . . . . . . . . . . . 5
5. Other issues . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security considerations . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Network managers currently prefer to Provider Independent (PI)
addressing for IPv6 to attempt to minimize the need for future
possible renumbering. However, widespread use of PI addresses may
create very serious 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 aims to solve the HNP renumbering
problem when the HNP in PMIPv6 [RFC5213] is not a PI type.
2. Usage scenarios
There are a number of reasons why the HNP renumbering support is a
useful. 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
the HNP renumbering may happen if the PMIPv6 service provider
switches to a different ISP.
Yan, et al. Expires October 14, 2015 [Page 2]
Internet-Draft PMIPv6 HNP Renumbering April 2015
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 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), when the home network prefix changes
(maybe due to 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
detects 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 the [RFC5213] (Section 6.12), the related solution has
not been specified.
3. Protocol
When the HNP renumbering happens in PMIPv6, the LMA has to notify the
new HNP to the MAG that has to announce the new HNP to the MN
accordingly. Also, the LMA and the MAG must delete the created
routing states for the renumbered prefix. To support this procedure,
[RFC7077]can be adopted which specifies asynchronously update from
the LMA to the MAG about the updated 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 October 14, 2015 [Page 3]
Internet-Draft PMIPv6 HNP Renumbering April 2015
+-----+ +-----+ +-----+
| MN | | MAG | | LMA |
+-----+ +-----+ +-----+
| | |
| | Allocate new HNP
| | |
| |<------------- UPN ---|
| | |
| Update routing status |
| | |
|<-----RA/DHCP --------| |
| | |
HoA Configuration | |
| | |
| |--- UNA ------------->|
| | |
| | Update routing status
| | |
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 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 an 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 October 14, 2015 [Page 4]
Internet-Draft PMIPv6 HNP Renumbering April 2015
The information of LMA is the basic configuration information of MAG.
When the LMA changes, the related profile should be updated by the
operator. 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.
Accordingly, the MAG will withdraw the old HNP information of the MN
and advise the new HNP to the MN as related steps in Section 3.1.
4. 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
When the RA message is used by the MAG to advise the new HNP, two
Prefix Information options are contained in the RA message [RFC2461].
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 address 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].
5. Other issues
In order to maintain the reachability of the MN, the 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.
6. 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.
Other security issues will be analyzed further.
Yan, et al. Expires October 14, 2015 [Page 5]
Internet-Draft PMIPv6 HNP Renumbering April 2015
7. Normative References
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui,
"Runtime Local Mobility Anchor (LMA) Assignment Support
for Proxy Mobile IPv6", RFC 6463, February 2012.
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
Network Renumbering Scenarios, Considerations, and
Methods", RFC 6879, February 2013.
[RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and
J. Korhonen, "Update Notifications for Proxy Mobile IPv6",
RFC 7077, November 2013.
Authors' Addresses
Zhiwei Yan
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing 100190
China
EMail: yan@cnnic.cn
Yan, et al. Expires October 14, 2015 [Page 6]
Internet-Draft PMIPv6 HNP Renumbering April 2015
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 October 14, 2015 [Page 7]