draft-ietf-dmm-hnprenum-02.txt   draft-ietf-dmm-hnprenum-03.txt 
DMM Working Group Z. Yan DMM Working Group Z. Yan
Internet-Draft CNNIC Internet-Draft CNNIC
Intended status: Standards Track J. Lee Intended status: Standards Track J. Lee
Expires: November 21, 2016 Sangmyung University Expires: January 2, 2017 Sangmyung University
X. Lee X. Lee
CNNIC CNNIC
May 20, 2016 July 1, 2016
Home Network Prefix Renumbering in PMIPv6 Home Network Prefix Renumbering in PMIPv6
draft-ietf-dmm-hnprenum-02 draft-ietf-dmm-hnprenum-03
Abstract Abstract
In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node
(MN) is assigned with a 64-bit Home Network Prefix (HNP) during its (MN) is assigned with a Home Network Prefix (HNP) during its initial
initial attachment for the Home Address (HoA) configuration. During attachment and the MN configures its Home Address (HoA) with the HNP.
the movement of the MN, this prefix remains unchanged and in this way During the movement of the MN, the HNP is remained unchanged to keep
it is unnecessary for the MN to reconfigure its HoA and reconnect the ongoing communications associated with the HoA. However, the current
ongoing communications. However, the current PMIPv6 specification PMIPv6 specification does not specify related operations when an HNP
does not specify related operations to support the MN to timely renumbering is happened. In this document, a solution to support the
receive and use a new HNP when the allocated HNP changes. In this HNP renumbering is proposed, as an update of the PMIPv6
draft, a solution to support the HNP renumbering is proposed, as an specification.
update of the PMIPv6 specification.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] document are to be interpreted as described in [RFC2119]
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 48 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 21, 2016. This Internet-Draft will expire on January 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Usage scenarios . . . . . . . . . . . . . . . . . . . . . . . 2 2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 2
3. PMIPv6 extensions . . . . . . . . . . . . . . . . . . . . . . 3 3. PMIPv6 Extensions . . . . . . . . . . . . . . . . . . . . . . 3
4. Session connectivity . . . . . . . . . . . . . . . . . . . . 5 4. Session Connectivity . . . . . . . . . . . . . . . . . . . . 5
5. Message format . . . . . . . . . . . . . . . . . . . . . . . 5 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 6
6. Other issues . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security considerations . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
Network managers currently prefer Provider Independent (PI) Network managers currently prefer Provider Independent (PI)
addressing for IPv6 to attempt to minimize the need for future addressing for IPv6 to attempt to minimize the need for future
possible renumbering. However, widespread use of PI addresses may possible renumbering. However, a widespread use of PI addresses may
cause Border Gateway Protocol (BGP) scaling problems. It is thus cause Border Gateway Protocol (BGP) scaling problems. It is thus
desirable to develop tools and practices that may make IPv6 desirable to develop tools and practices that make IPv6 renumbering a
renumbering a simpler process to reduce demand for IPv6 PI space simpler process to reduce demand for IPv6 PI space [RFC6879]. In
[RFC6879]. In this draft, we aim to solve the HNP renumbering this document, we aim to solve the HNP renumbering problem when the
problem when the HNP in PMIPv6 [RFC5213] is not the type of PI. HNP in PMIPv6 [RFC5213] is not the type of PI.
2. Usage scenarios 2. Usage Scenarios
There are a number of reasons why the HNP renumbering support in There are a number of reasons why the HNP renumbering support in
PMIPv6 is useful and a few are identified below: PMIPv6 is useful and some scenarios are identified below:
o Scenario 1: the PMIPv6 service provider is assigned with the HNP o Scenario 1: the HNP set used by a PMIPv6 service provider is
set from the (uplink) Internet Service Provider (ISP), and then assigned by a different Internet Service Provider (ISP), and then
the HNP renumbering may happen if the PMIPv6 service provider the HNP renumbering may happen if the PMIPv6 service provider
switches to a different ISP. switches to a different ISP.
o Scenario 2: multiple Local Mobility Anchors (LMAs) may be deployed o Scenario 2: multiple Local Mobility Anchors (LMAs) may be deployed
by the same PMIPv6 service provider, and then each LMA may serve 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 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 if the current serving LMA switches to another LMA but without
inheriting the assigned HNP set [RFC6463]. inheriting the assigned HNP set [RFC6463].
o Scenario 3: the PMIPv6 HNP renumbering may be caused by the re- o Scenario 3: the PMIPv6 HNP renumbering may be caused by the re-
building of the network architecture as the companies split, building of the network architecture as the companies split,
merge, grow, relocate or reorganize. For example, the PMIPv6 merge, grow, relocate, or reorganize. For example, the PMIPv6
service provider may reorganize its network topology. service provider may reorganize its network topology.
In the scenario 1, we assume that only the HNP is renumbered while 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 the serving LMA remains unchanged and this is the basic scenario
this document. In the scenario 2 and scenario 3, more complex considered in this document. In the scenario 2 and scenario 3, more
results may be caused, for example, the HNP renumbering may happen complex results may be caused, for example, the HNP renumbering may
due to the switchover of serving LMA. happen due to the switchover of a serving LMA.
In the Mobile IPv6 (MIPv6) protocol, when the home network prefix In the Mobile IPv6 (MIPv6) protocol, when a home network prefix
changes (may also be caused by the above reasons), the Home Agent changes, the Home Agent (HA) will actively notify the new prefix to
(HA) will actively notify the new prefix to the MN and then the its MN and then the renumbering of the Home Network Address (HoA) can
renumbering of the HoA can be well supported [RFC6275]. While in the be well supported [RFC6275]. In the basic PMIPv6, the PMIPv6 binding
basic PMIPv6, the PMIPv6 binding is triggered by the Mobile Access is triggered by a Mobile Access Gateway (MAG), which detects the
Gateway (MAG), which detected the attachment of the MN. When the HNP attachment of the MN. A scheme is also needed for the LMA to
renumbering happens, a scheme is also needed for the LMA to immediately initiate the PMIPv6 binding state refreshment during the
immediately initiate the PMIPv6 binding state refreshment. Although HNP renumbering process. Although this issue is also mentioned in
this issue is also discussed in Section 6.12 of [RFC5213], the Section 6.12 of [RFC5213], the related solution has not been
related solution has not been specified. specified.
3. PMIPv6 extensions 3. PMIPv6 Extensions
When the HNP renumbering happens in PMIPv6, the LMA has to notify the When the HNP renumbering happens in PMIPv6, the LMA has to notify a
new HNP to the MAG and then the MAG has to announce the new HNP to new HNP to an MAG and then the MAG has to announce the new HNP to the
the MN accordingly. Also, the LMA and the MAG must update the attached MN accordingly. Also, the LMA and the MAG must update the
routing states for the prefixes. To support this procedure, routing states for the HNP and the related addresses. To support
[RFC7077] can be adopted which specifies asynchronously update from this procedure, [RFC7077] can be adopted which specifies an
the LMA to the MAG about the session parameters. This document asynchronous update from the LMA to the MAG about specific session
considers the following two cases: parameters. This document considers the following two cases:
(1) HNP is renumbered in the same LMA (1) HNP is renumbered under the same LMA
In this case, the LMA remains unchanged as in the scenario 1 and In this case, the LMA remains unchanged as in the scenario 1 and
scenario 3. The operation steps are shown in Figure 1. scenario 3. The operation steps are shown in Figure 1.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| MN | | MAG | | LMA | | MN | | MAG | | LMA |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | |
| | Allocate new HNP | | Allocate new HNP
| | | | | |
| |<------------- UPN ---| | |<------------- UPN ---|
| | | | | |
| Update routing state | | | |
| | | | | |
|<-----RA/DHCP --------| | |<-----RA/DHCP --------| |
| | | | | |
HoA Configuration | | Address configuration | |
| | | | | |
| |--- UNA ------------->| | Update binding&routing states |
| | | | | |
| | Update routing state | |--- UPA ------------->|
| | |
| | Update binding&routing states
| | | | | |
Figure 1: Signaling call flow of HNP renumbering Figure 1: Signaling call flow of the HNP renumbering
o When the PMIPv6 service provider renumbers the HNP set in the same o When a PMIPv6 service provider renumbers the HNP set under the
LMA, the serving LMA will initiate the HNP renumbering operation. same LMA, the serving LMA will initiate the HNP renumbering
The LMA allocates a new HNP for the related MN. operation. The LMA allocates a new HNP for the related MN.
o The LMA sends the Update Notification (UPN) message to the MAG to o The LMA sends the Update Notification (UPN) message to the MAG to
update the HNP information. If the Dynamic Host Configuration update the HNP information. If the Dynamic Host Configuration
Protocol (DHCP) is used in PMIPv6 to allocate the HoA, the new HNP Protocol (DHCP) is used to allocate the address, the new HNP
should be also notified to the DHCP infrastructure. should be also notified to the DHCP infrastructure.
o After the MAG receives this UPN message, it recognizes that the o Once the MAG receives this UPN message, it recognizes that the
related MN has a new HNP. Then the MAG should notify the MN about related MN has the new HNP. Then the MAG should notify the MN
the new HNP with a Router Advertisement (RA) message or allocate a about the new HNP with a Router Advertisement (RA) message or
new address within the new HNP with a DHCP message. allocate a new address within the new HNP through a DHCP
procedure.
o When the MN obtains the new HNP information, it deletes the old o After the MN obtains the HNP information through the RA message,
HoA and configures a new HoA with the newly allocated HNP. 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) o When the new HNP is announced or the new address is configured to
to the LMA for the notification of successful update of the HNP, the MN successfully, the MAG updates the related binding and
related binding state, and routing state. Then the LMA updates routing states. Then the MAG sends back the Update Notification
the routing information corresponding to the MN to replace the old Acknowledgement (UPA) message to the LMA for the notification of
HNP with the new one. successful update of the HNP, related binding state, and routing
state. Then the LMA updates the routing and binding information
corresponding to the MN to replace the old HNP with the new one.
(2) HNP renumbering caused by LMA switchover (2) HNP renumbering caused by the LMA switchover
Because the HNP is assigned by the LMA, the HNP renumbering may be Since 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. caused by the LMA switchover, as in the scenario 2 and scenario 3.
The information of LMA is the basic configuration information of MAG. The information of LMA is the basic configuration information of MAG.
When the LMA changes, the related profile should be updated by the When the LMA changes, the related profile should be updated by the
service provider. In this way, the MAG will initiate the re- service provider. In this way, the MAG initiates the registration to
registration to the new LMA as specified in [RFC5213]. When the HNP the new LMA as specified in [RFC5213]. When the HNP renumbering is
renumbering is caused in this case, the new HNP information will be caused in this case, the new HNP information is sent by the LMA
sent by the LMA during the new binding procedure. Accordingly, the during the new binding procedure. Accordingly, the MAG withdraws the
MAG will withdraw the old HNP information of the MN and advise the old HNP of the MN and announces the new HNP to the MN as like the
new HNP to the MN as the 3rd Step in Section 3(1). case of the HNP is renumbered under the same LMA.
4. Session connectivity 4. Session Connectivity
HNP renumbering may cause the disconnection of the ongoing The HNP renumbering may cause the disconnection of the ongoing
communications of the MN. Basically, there are two modes to manage communications of the MN. Basically, there are two modes to manage
the session connectivity during the HNP renumbering. the session connectivity during the HNP renumbering.
(1) Soft-mode (1) Soft-mode
The LMA will temporarily maintain the state of the old HNP during the The LMA will temporarily maintain the state of the old HNP during the
HNP renumbering (after the UNA reception) in order to redirect the HNP renumbering (after the UPA reception) in order to redirect the
packets to the MN before the MN reconnects the ongoing session and packets to the MN before the MN reconnects the ongoing session and
notifies its new HoA to the Correspondent Node (CN). This mode is notifies its new HoA to the Correspondent Node (CN). This mode is
aiming to reduce the packet loss during the HNP renumbering but the aiming to reduce the packet loss during the HNP renumbering but the
binding state and routing entry corresponding to the old HNP should binding state corresponding to the old HNP should be marked for
be marked for example as transient binding [RFC6058]. This temporary example as transient binding [RFC6058]. This temporary binding
binding should only be used for the downwards packet transmission and should only be used for the downwards packet transmission and the LMA
the LMA should not broadcast the routing information about the old should stop broadcasting the routing information about the old HNP if
HNP if it is no longer anchored at this LMA. the old HNP is no longer anchored at this LMA.
(2) Hard-mode (2) Hard-mode
If the HNP renumbering happens with the switchover of the LMA, the If the HNP renumbering happens with the switchover of the LMA, the
hard-mode is recommended to keep the protocol simple and efficient.In hard-mode is recommended to keep the protocol simple. In this mode,
this mode, the LMA will delete the state of the old HNP after it the LMA deletes the binding state of the old HNP after it receives
receives the UNA message from MAG and the LMA will silently discard the UPA message from the MAG and the LMA silently discards the
the packets destined to the old HNP. packets destined to the old HNP.
5. Message format 5. Message Format
(1) UPN message (1) UPN message
In the UPN message sent from the LMA to the MAG, the notification In the UPN message sent from the LMA to the MAG, the notification
reason is set to 2 (UPDATE-SESSION-PARAMETERS). Besides, the HNP reason is set to 2 (UPDATE-SESSION-PARAMETERS). Besides, the HNP
option containing the new HNP and the Mobile Node Identifier option Option [RFC5213] containing the new HNP and the Mobile Node
carrying Identifier of MN are contained as Mobility Options of UPN. Identifier Option [RFC4283] carrying identifier of MN are contained
as Mobility Options of UPN. The order of HNP Option and Mobile Node
Identifier Option in the UPN message is not mandated in this draft.
(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. When the MAG did not
successfully renumber the HNP which is required in the UPN message,
the Status Code of 128 is set in the UPA message and the following
operation of LMA is PMIPv6 service provider specific.
(3) RA Message
(2) RA Message
When the RA message is used by the MAG to advise the new HNP, two When the RA message is used by the MAG to advise the new HNP, two
Prefix Information options are contained in the RA message [RFC4861]. Prefix Information Options are contained in the RA message [RFC4861].
In the first Prefix Information option, the old HNP is carried but In the first Prefix Information Option, the old HNP is carried but
both the related Valid Lifetime and Preferred Lifetime are set to 0. both the related Valid Lifetime and Preferred Lifetime are set to 0.
In the second Prefix Information option, the new HNP is carried with In the second Prefix Information Option, the new HNP is carried with
the Valid Lifetime and Preferred Lifetime set to larger than 0. the Valid Lifetime and Preferred Lifetime set to larger than 0.
(3) DHCP Message (4) DHCP Message
When the DHCP is used in PMIPv6 to configure the HoA for the MN, a When the DHCP is used in PMIPv6 to configure the addresses for the
new IPv6 HoA is generated based on the new HNP. Trigged by the UPN MN, new IPv6 address(es) (e.g., HoA) will be generated based on the
message, the MAG will request the new HoA from the DHCP server first new HNP and the related DHCP procedure is also triggered by the
and then the MAG updates the allocated HoA to the MN through the DHCP reception of UPN message [RFC3315].
server-initiated configuration exchange [RFC3315].
6. Other issues 6. Other Issues
In order to maintain the reachability of the MN, the Domain Name In order to maintain the reachability of the MN, the Domain Name
System (DNS) resource record corresponding to this MN may need to be System (DNS) resource record corresponding to this MN may need to be
updated when the HNP of MN changes [RFC3007]. However, this is out updated when the HNP of MN changes [RFC3007]. However, this is
the scope of this draft. beyond the scope of this document.
7. Security considerations 7. Security Considerations
This extension causes no further security problem. The security The protection of UPN and UPA messages in this document follows
considerations in [RFC5213] and [RFC7077] are enough for the basic [RFC5213] and [RFC7077]. This extension causes no further security
operation of this draft. problem.
8. IANA Considerations 8. IANA Considerations
This document presents no IANA considerations. This document presents no IANA considerations.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 7, line 10 skipping to change at page 7, line 27
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
<http://www.rfc-editor.org/info/rfc3007>. <http://www.rfc-editor.org/info/rfc3007>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>. 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, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>. <http://www.rfc-editor.org/info/rfc4861>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008, RFC 5213, DOI 10.17487/RFC5213, August 2008,
<http://www.rfc-editor.org/info/rfc5213>. <http://www.rfc-editor.org/info/rfc5213>.
skipping to change at page 8, line 15 skipping to change at page 8, line 35
CNNIC CNNIC
No.4 South 4th Street, Zhongguancun No.4 South 4th Street, Zhongguancun
Beijing 100190 Beijing 100190
China China
EMail: yan@cnnic.cn EMail: yan@cnnic.cn
Jong-Hyouk Lee Jong-Hyouk Lee
Sangmyung University Sangmyung University
31, Sangmyeongdae-gil, Dongnam-gu 31, Sangmyeongdae-gil, Dongnam-gu
Cheonan Cheonan 31066
Republic of Korea Republic of Korea
EMail: jonghyouk@smu.ac.kr EMail: jonghyouk@smu.ac.kr
Xiaodong Lee Xiaodong Lee
CNNIC CNNIC
No.4 South 4th Street, Zhongguancun No.4 South 4th Street, Zhongguancun
Beijing 100190 Beijing 100190
China China
 End of changes. 48 change blocks. 
118 lines changed or deleted 139 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/